RE: Basic Cert-2-Directory mapping question

["Bob Jueneman" <bjueneman@xxxxxxxxxx>]

Skip, as you correctly point out, the problem is not so great in the case 
of an organization that operates its own DNS domain, and uses that domain
as the means of providing directory service access. Certainly a company 
like Novell, Lockheed, GTE (oops, Verizon), etc., could easily do so.

But notice some of the problems.  I'm not picking on our esteemed co-chair, but
notice that Steve's e-mail address, kent@xxxxxxx, is two corporate mergers
behind the times, since GTE acquired BBN, and then Verizon was formed out 
of GTE and Bell Atlantic. But if his certificate were deposited at something like
directory.verizon.com, how would you extract that from the BBN name?
would all of those older e-mail address have to have a set of alias DNS names for
the directory server?

With smaller organizations, the problem is much worse.  A small law firm, for
example, may or may not operate their own domain name, either for web 
purposes or for e-mail.  Some do, but many are still using commercial services 
such as earthlink, pipeline, etc.

A company may decide to operate their own domain, either physically, or by 
outsourcing the server with their own domain name to an ISP or ASP.

But in either case, that doesn't necessarily mean that they would choose to 
host their own directory service, and perhaps especially not for certificates.

Instead, they might opt to leave that functionality up to the CA that issued
the certificates, for example VeriSign.  

Or perhaps they create their own certificates, using a toolkit such as is 
provided by Entrust, Baltimore Technologies, Microsoft, or Novell.  In
that case, they might choose to contract with a Trusted Repository,
someone who chooses to take on the responsibility of operating a 24x7, 
high availability directory server and/or OCSP provider, such as Digital 
Signature Trust. (Note that creating certificates does not require that type 
of availability.  The Pasadena Ladies Garden Club can issue certs to 
all of their members once a year, and never turn the server back on again 
until next year.)

And then we have the problem of the mom and pop residential user.
The path of least resistance might be for them to publish their certificate
with their ISP, for example Yahoo, AOL, or MSN.

But what if they later decide to switch e-mail service providers.  Are they
they then obligated to get new certificates, even though the old ones 
haven't expired yet? And what does that do to the concept of validation
of still valid certs for binding transactions?

It is for these kinds of reasons that I believe that any form of generally 
workable directory locator scheme CANNOT POSSIBLY be based 
on a deterministic relationship between the location of the directory and 
a web address or e-mail address per se, simply because the directory 
service provider may have nothing whatsoever to do with those other 
services.

Instead, I believe that we should either use some kind of a URL prefix
that identifies the type of access protocol followed by the DNS name of the 
service, followed by the DN that you are trying to look up, assuming 
that is what you are trying to do.

An example might look like ldap://ldap.mydirectory.com/rfc822=myname@xxxxxxxxx, 

Another possibility would be what John Wray suggested:

dir="directory.VeriSign.com", c=us, st=ut, l=provo, cN="Robert R. Jueneman"

I'm assuming in this case that the port number of the directory service can 
be provided by default within the "dir" component, otherwise it may have 
to be provided specifically.

I'd be interested in your thoughts, as it seems that you may be thinking 
about something similar to the second example.

Once we can at least find the appropriate directory, we can concentrate 
on how to ensure schema compatibility between the directory and the
certificate.  But I believe that if the certificate subscriber gets to pick 
the directory provider, then these problems can be accommodated rather 
easily, and certainly if the directory service provider is the CA.

It is when someone tries to cram a certificate willy-nilly into a directory
without any prior coordination that the problems really become intractable.

Regards,

Bob


>>> "Slone, Skip" <skip.slone@xxxxxxxx> 01/10/01 12:17PM >>>
As the traffic on this topic points out, there are a lot of people who see
this as an issue.  Whether we can agree on exactly what the issue is and how
to proceed may be another matter ... :-)

As have many others on this list, I've been giving this issue some thought
lately, focusing on the problems as seen from the perspective of a large
user like my company. Although I've come to a different set of conclusions
from those discussed so far in this thread, my energy has been focused on
the same problem that Bob Jueneman pointed out: knowing the location of a
directory service provider that is supposed to contain the DN. 

My basic premise is that if we can come up with a deterministic algorithm
that takes an arbitrary (but reasonably well structured) DN and resolves it
to a set of FQDNs where one can find LDAP services, we can deterministically
get from the DN to the associated directory entry.  As Steve Kent pointed
out, there exists a body of work to do this in the limited case of DNs based
on (DNS) domainComponent naming.  My thoughts are along that line, but
expand to cover the so-called "civil" naming constructs in DNs, such as
country, organization, and so on.  I think that's the goal Anders originally
stated, starting this whole thread.

If people are interested, I'll summarize the algorithm I've come up with so
far and distribute it for review.  If need be, we could consider whether
this is worthy of an I-D, or a BOF at Minneapolis, or whatever...

Regards,

 -- Skip Slone
    Lockheed Martin