Subject: RE: Basic Cert-2-Directory mapping question

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 10 Jan 2001 13:59:06 -0700

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, [email-masked], 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=[email-masked], 

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" <[email-masked]> 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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Jan 2001 16:45:09 -0500

Bob,

>would all of those older e-mail address have to have a set of alias 

Life is a bit more complicated than your example suggests.  I still 
work at BBN, BBN Technologies, a part of Verizon. We still own the 
domain name BBN, and we're getting our own logo again, so mergers and 
acquisitions don't always warrant wholesale changes! My GTE 
colleagues probably do need to change over to new, Verizon e-mail 
addresses, over time, but not instantly. The GTE and Bell Atlantic 
logo change will be phased over about 2 years, in the physical arena, 
so one could expect a similar grace period in cyberspace. Also, it 
would not be unreasonable for a Verizon directory to provide links to 
BBN, just as people often maintain multiple e-mail addresses, with 
appropriate internal links, to smooth over transitions of this sort. 
(I'm [email-masked], but [email-masked] works, and [email-masked] 
works too!)

<snip>

Steve

---

From: Aram Perez <[email-masked]>
Date: Wed, 10 Jan 2001 15:10:59 -0800

Stephen Kent wrote:

[snip]
> (I'm [email-masked], but [email-masked] works, and [email-masked]

So now you will get three times as much spam from the spammers that use the
PKIX mailing list!

;-)
Aram Perez

---

From: Michael Ströder <[email-masked]>
Date: Thu, 11 Jan 2001 11:01:10 +0100

Bob Jueneman wrote:
> 
> But notice some of the problems.  I'm not picking on our
> esteemed co-chair, but notice that Steve's e-mail address,
> [email-masked], is two corporate mergers behind the times,

So what? I don't care about his e-mail address at all. I did not
even look at it! Could be hotmail.com, earthlink.net, web.de or
whatever. It does not carry any information for me.

The most important thing to me as a user is to reach *him* under
this e-mail address *he* used as from address. And if I'm really
paranoid I try to get a hold of *his* certificate. And the CA would
have to revoke *his* certificate if *he*'s not reachable under this
e-mail address anymore.

> 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.

Yes, which leads to Anders' question how to map one certificate in
several directories. In this case you're maintaining your directory
to hold certificates of your e-mail partners (I still did not find
the time to write an e-mail filter which automatically pulls out the
certs found in signed e-mails passing a mail relay and puts them
into a LDAP directory).

> 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?

YES!

> And what does that do to the concept of validation

Revoke the certs for the old e-mail address if they're not using it
anymore => binding will fail. Or did I get you wrong?

> 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

We already have primary DNS servers which can give authorative
answers for DNS domains. For a deterministic relationship between
the location of the directory and a web address or e-mail address we
need "primary directory servers" which are responsible for holding
e.g. dc=stroeder,dc=com. I see no reason why I shouldn't be able to
delegate this to a directory service provider similar to my ISP
being responsible for managing *my* DNS domain stroeder.com. And
sure they can be different service providers.

For those not having their own domain directory servers for
hotmail.com, earthlink.net, web.de etc. could hold the directory
entries (or delegate it to another provider).

Locating the directory services and a person's entry would be pretty
easy by using the e-mail address, RFC2377 and/or a service like
ldap://root.openldap.org without any new standards.

Ciao, Michael.

---

From: Oscar Jacobsson <[email-masked]>
Date: Thu, 11 Jan 2001 14:02:09 +0100

> certs found in signed e-mails passing a mail relay and puts them

Mapping one certificate to many directories doesn't seem to hard to
accomplish using SRV records, given that the certificate is named in
accordance to RFC 2377.

For purposes of local mirroring however, explicit configuration is
probably required in order to have local RPs query the local "cache"
before, or as a complement to querying external repositories. This would
probably also have to cater for the vast amount of arbitrarily named
certificates currently in circulation.

> entries (or delegate it to another provider).

The party certifying, say, a webmail.example e-mail address does not
need to be "authoritative" for that domain. A given third party, in this
case ttp.example, could issue the webmail certificate using a 'dc=ttp,
dc=example' DN with the webmail.example e-mail address as an subject
alternate name, directing RPs to query ttp.example responders instead of
webmail.example ones.

This is one way different providers can be selected for hosting e-mail
and directory services.

//oscar