Access control use-cases

[Norman Gray]

Guy, hello.

On 2006 Jul 12 , at 11.39, Guy Rixon wrote:

> On Wed, 12 Jul 2006, Norman Gray wrote:

>> Thanks for this -- I've added a suitable case to the list, making the
>> general observation that access isn't necessarily a simple function
>> of identity, but will depend on other factors, or other features of
>> the certificate, which will vary in time.
>
> Being picky, I would say that, in this case, a different  
> certificate implies a
> different identity, so access rights _are_ just a function of  
> identity.

Is this the general definition of identity in the X.509 world?  It  
seems contrary to conflate the idea of identity with that of a  
certificate.

X.509 says `[e]ach user is identified by its possession of its  
private key', and `[a]uthentication relies on each user possessing a  
unique distributed name'.  Thus, without quite saying so explicitly  
(as far as I can see), X.509 seems to give both the DN and the  
private key some separate status as identifiers, and the CA's  
certificate merely asserts the link between them.

Thus,

>   /C=UK/O=eScience/CN=Norman Gray
>
> (strong certificataion) and
>
>  /C=UK/O=AstroGrid/OU=dodgy test CA/CN=Norman

A person can have multiple DNs; a DN can presumably have multiple  
keypairs; and a (DN,keypair) pair can presumably (in principle or in  
practice?) have multiple certificates, from different CAs, asserting  
the correspondence, or possibly asserting the link with various  
chunks of information in AlternativeNames.  Of course, in most cases,  
a DN would be associated with a single keypair and a single certificate.

Am I wildly out, here?

> In this
> case, the federation downgrades rights of the strongly-certified
> identity to those appropriate for the most-weakly-certified identity.

If I'm understanding you correctly, shouldn't this be the other way  
around, so that you get the union of the rights that each certificate  
would give you (monotonicity)?

> Perhaps we need consistent levels of strength of certification for
> interoperation? The three levels that seem managable are:
>
>  - Has working email address (as originally suggested by
>    Ray Plante in respect of weak CAs).
>
>  - Known to local RA/CA within VObs community (AstroGrid's
>    community model).
>
>  - Approved by national-level grid Policy Management Authority
>    (having given DNA sample or first-born child as hostage or  
> whatever).

Organisations like Thawte seem to have a similar set of assurance  
levels, but there appears to be no standardised way of indicating  
which one's which.  It _appears_ that what the relyer has to do is  
deduce which type of certificate is which, based on the presence or  
absence of various attributes, and then compare those with the CA's  
Certification Practice Statement, to decide if the assurance for the  
certificate is adequate for the relyer's purposes.  In other words,  
that's special-case code, though it only has to be done once for each  
CA the resource owner cares about.

All the best,

Norman


-- 
------------------------------------------------------------------------ 
----
Norman Gray  /  http://nxg.me.uk
eurovotech.org  /  University of Leicester, UK