Re: Basic Cert-2-Directory mapping question

[Oscar Jacobsson <oscar.jacobsson@xxxxxxxxxxx>]

Sharon Boeyen wrote:
> The naming scheme (at least the higher levels of it) that is being
> referenced is
> originally outlined in an informative annex to X.521 and its also in
> some LDAP specs.

Ah, all right. I was of the mistaken impression that it was a more or
less arbitrary naming scheme. Should have done my homework better.

> Rather than try to name the world and every object in it, ...

I took the liberty of trimming your soapbox address, because we are
using rather different scopes as the bases for our arguments, so I'd
much rather begin by explaining mine:

What I am proposing is "simply" to name every directory server on the
Internet (which I think the DNS does a very good job of) and
subsequently to name every entry in all these directories (which I think
can safely be left up to local administrators).

The PKIX charter states the intent of the group as "developing Internet
standards needed to support an X.509-based PKI". To develop a new
standard, or to endorse those already existing, for how certificates
(and thus the directory entries they may certify) should be named in
order to be usable (please see the discussion on requirements/use cases
below) over the Internet seems like a worthwhile endeavour.

And while on the subject of naming, didn't Rosseau in his day propose
the abolition of common nouns all together? It would be interesting to
know what naming schemes he proposed. :-)

> However, I really would like to see us work from a focused
> 'requirements' standpoint rather
> than from the abstract level that a lot of this thread seems to have.

Definitely. I feel cases could be argued far better formally, backed by
specific use cases and requirements.

Just as an OTOH example, these are a few use cases I would want an
Internet-based naming scheme to address:

1. Allowing RPs to discover the location of the directory in which the
subject entry resides, from which additional attributes could be
retreived as required.

2. Allowing RPs to discover the location of the directory in which the
issuer entry resides, from which additional attributes -- specifically
revocation lists -- could be retreived as required.

3. Allowing RPs to discover the location of the directory in which the
cRLDistributionPoint entry resides, from which revocation lists could be
retreived as required.

Regards,

//oscar