Access control use-cases
norman at astro.gla.ac.uk
Wed Jul 12 07:24:57 PDT 2006
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
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
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.
> /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
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 Gray / http://nxg.me.uk
eurovotech.org / University of Leicester, UK
More information about the grid