Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 14 Feb 2003 12:07:58 -0800

> >> May be in different environments different such 
> technologies might be
> >> usefull. What I am missing in this discussion is a clear list of
> >> requirements for certificate retrieval.
> > 
> > Alice wants to send email to Bob
> > Alice does not know Bob's Certificate
> > Alice does know Bob's email address.
> > Bob's name is not unique
> 
> But Bob's email is unique. Why can't Alice look up Bob's 
> certificate by his
> unique email address?

That is the whole big-thing point as Rowan Atkinson would say.

> Can you please restate exactly what this "Web of Trust cert 
> path discovery
> requirement" is?

OK, you want to sent a meesage from UC Irvine to the Sorbone Paris.
There is a certification path through the HEBCA bridge, the 
FBCA, le Ponte Authoritee Certification Franglaise and le Ecole
Nationalle Ponte Authoritee Certification.

So to get from A to B you have to know that there is a trust
relationship that goes through the four bridge CAs, it is also a pretty
strong one that is maintained under fairly strict scrutiny. But getting
from A to B is going to be either inefficient or impossible unless you
know that there is a structure here you can exploit.

Cf the difficulty of IP routing without the concept of clouds.

		Phill

---

From: Aram Perez <[email-masked]>
Date: Fri, 14 Feb 2003 13:42:58 -0800

> That is the whole big-thing point as Rowan Atkinson would say.

I'm afraid I don't understand. AFAIK, LDAP/X.500/SQL all can be set up to
return a certificate given a unique email. Is the issue that
companies/organizations do not set up their LDAP/X.500/SQL data stores to
allow this?

> know that there is a structure here you can exploit.

So how does something like XKMS solve this? Because it appears that the
issue is not just Alice getting Bob's certificate, it's how does Alice get
all the intermediate certificates (that may or may not have a unique email).

Aram