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.
In some countries this type of naming is being more readily adopted than in others. It
is my VERY strong belief that trying to impose a single naming structure or a single naming
hierarchy for all applications and all environments simply is a recipe for disaster. The US
has historically been the absolute most difficult place to do this in the past (reference
the North American Directory Forum effort that Bob references). Regulatory differences and
differing business models and operating environments lead to different naming structures.
Borrowing from Marshall Rose's writing style, let me step on my soapbox for a minute:
Rather than try to name the world and every object in it, I believe a more constructive approach
is to accept the fact that different parts of the world and different environments will have
use a variety of nameforms and work within that context to make the best use of the tools we have
at our disposal to find the information that is needed. We should not be trying to solve the "global
directory problem", we are the PKIX WG. We should ensure that appropriate PKIX information can be located and
retrieved. We are not the global naming police either and should not try to impose the rules that
anyone uses to name entities to which they issue certificates. Finding a particular certificate is
one problem and determining whether or not to 'trust' and make use of it is another. Repository
locator discussions should be restricted to the former.
Step off soapbox.
I do agree that 2377 and the PKIX repository locator document are a nice fit and will satisfy a
lot of the requirement for many environments. Those that use the geographical, DNS or other style
of DNs for the certs and directories can all be supported for applications where the domain name is
known. There may however be some additional support tools that can defined to ease the 'knowledge'
gathering process as Skip suggests. One that was raised earlier on the list and for which we don't yet
have an answer is the provision of search base data for LDAP SRV records for PKI repositories. If there
is a way to add additional information to DNS that will help resolve these types of issues then I'm
all for it. Another option that might be worth exploring is piggybacking repository locator information
in certificate management protocols (e.g. when one CA sends a cert request to another CA it could provide
the details of how to access its repository in that cert requests - it is relying parties from the issuer's
domain that will need that access). Again that won't satisfy every case, since strict hierarchies that
don't cross-certify with other domains wouldn't be covered). Skip, I'm not necessarily objecting to the
mapping you are proposing, but am trying to understand within the context of PKI requirements and I'm not
quite there yet :-)
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.
Sharon
> -----Original Message-----
> From: Oscar Jacobsson [mailto:oscar.jacobsson@xxxxxxxxxxx]
> Sent: Thursday, January 11, 2001 4:47 AM
> To: Slone, Skip
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: Basic Cert-2-Directory mapping question
>
>
> "Slone, Skip" wrote:
> > Since civil-to-DNS name mapping typically fails to yield to a
> > character string transliteration algorithm (e.g., "o=Joe's Bar and
> > Grill" does not readily translate to are-you-hungry.com),
> this leaves
> > us with a choice of either registering the translations or
> > complaining that it can't be done.
>
> Pardon my ignorance of these matters, but where exactly is this civil
> naming scheme outlined?
>
> IMHO the DNS-based naming scheme for in RFC 2377 has been around for a
> couple years now, and when combined with the repository locator
> documents I'd say it provides the information necessary for an RP to
> locate the relevant repository.
>
> //oscar
>