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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 14 Feb 2003 06:59:52 -0800

> To summarize this thread it seems that following technologies 
> have been 
> proposed to publish X.509 certificates:
> LDAP/X.500, DNS, HTTP (CertStore) and XML (XKMS). A new draft on Web 
> Services seems to be on its way.

No, XKMS is a Web Service. It is OSCPII and its competitors that are
on their way.

> 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
Bob's company will not provide any form of search capabilities beyond
exact match.
The Trust topology is complex as in a multiple bridge CA Web of trust.

XKMS and the planned ASN.1 cert discovery protocols meet these
requirements

X.500/LDAP are designed to meet different requirements. They cannot
address the Web of Trust cert path discovery requirement.

> 
> As to LDAP/X.500:
> 
> Michael has shown that most arguments against LDAP/X.500, 

He showed no such thing. His arguments were flat and unconvincing
except if you are already sold on LDAP/X.500.

My empiriacal observation is that companies that try to deploy a 
Directory based PKI fail far more frequently than those who do 
not make the directory a critical path component, or make the 
directory deployment completely subordinate to the PKI.

The problem is that Directories offer companies infinite scope
for arguing over the structure of DITs etc. The fact that these 
arguments are important demonstrate the basic immaturity of 
directory technology.

> e.g. privacy 
> issues, organisations not willing to publish information about their 
> employess, etc. also hold true for the other technologies.

This is empirically wrong. Most VeriSign customers are prepared
to publish their certificats in the public directory for retrieval
on the basis of exact match of email address.

> I vote for LDAP, since it provides an established network 
> protocol and 

The customers vote for no-LDAP and have done for the past ten years.

> Our proposal for storing certs in LDAP 
> (draft-klasen-ldap-x509certificate-schema) provides the 
> possibility to 
> create a distributed certificate repository, where every CA 
> can publish 
> their certs in a DIT structure to their liking (

That is the problem, to their liking means no interoperability.

> With the help of an indexing system and the LDAP referral 
> mechanism  a 
> service can be established that can refer an LDAP client to the LDAP 
> server on which the certificate searched for is stored. The 
> alternative 
> using DNS SRV for locating servers has been mentioned in this thread 
> already.

I originally proposed the SRV mechanism. It can locate a certificate
server but it cannot locate a certification path.

> Peter Gu.: if you don't know whether to laugh or cry about 
> our proposal, 
> please consider that
> 
> ldap:///?caCertificate?sub?
>     	(&(objectClass=x509certificate)(x509subjectKeyIdentifier=%5CE6
>     	 %5C7A%5CD9%5C16%5C95%5C4A%5CE1%5C12%5C9F%5C22%5C09%5C6A%5C43%
>     	 5C83%5C78%5C25%5C70%5C52%5CE0%5C19))
> 
> is a bit more powerfull that the key/value pair you propose, 

I don't care how 'powerfull' a mechanism is. The point is that
power does not equal utility.

Less powerful frequently means more useful. C is a subset of the
CPL language and is better for it.

Directories are the ADA of network computing.

> X.500 bashing on this list is no new phenomenon, look at the pkix 
> archives and you will find similiar, e.g. quote:
>
>  From [email-masked]  Tue Mar 11 16:00:16 1997 [sic]:
>
> "Part of the recent success of X.509 in the internet space,
> given it lay on the internet doldrums for years, was its abandonment
> of X.500 as mandatory for theory or practice. One can, always
> add X.500 back in whenever one wants, of course; as much
> or as little as one wants."

If X.500 gets bashed it is probably because it deserves to.

The above comment is correct. PKI has succeeded in spite of directory
nonsense, not as a result.

Now that we have alternatives that actually meet our needs it is
time to give the unwellcome house guest their marching orders.

> In spite of X.500 bashings a consensus seemed to have 
> established from time to time in this group that LDAP 
> is a good technology for  certificate repositories. 

The only consensus I can see concerning certificate discovery is
that there is a need for a new protocol which duplicates most of
the functionality of XKMS in ASN.1 and then adds in some extra
twiddles. 

I don't agree that angle brackets are indigestible but it is
better for the group to persue the right architecture than to
continue to persue an architecture that has been an abject failure.

I don't count large numbers of enterprise directory sales as 
evidence for success. Try a thought experiment, what happens if
the directory goes down, how much work does that event stop
getting done?

	Phill

---

From: Aram Perez <[email-masked]>
Date: Fri, 14 Feb 2003 09:01:38 -0800

Hi Phill,

While I generally agree with what you write, this time I have do have some
questions, see below.

Regards,
Aram Perez

Hallam-Baker, Phillip wrote:

[snip]
> Alice does know Bob's email address.

But Bob's email is unique. Why can't Alice look up Bob's certificate by his
unique email address?

> address the Web of Trust cert path discovery requirement.

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

[snip]
> on the basis of exact match of email address.

Not exactly related, but why won't VeriSign "publish" or make available
their public keys so I can do my own manual verification of VeriSign's
certificates in my browser?

[snip]
> the directory goes down, how much work does that event stop

Come on Phill, what happens if any critical component goes down? Look at
what the Slammer virus did to the whole, worldwide Internet when it attacked
SQL servers (not LDAP servers).

---

From: Eric Norman <[email-masked]>
Date: Sat, 15 Feb 2003 17:03:52 -0600 (CST)

> But Bob's email is unique. Why can't Alice look up Bob's certificate by his

Going off on a tangent here, but it's a tangent that doesn't seem
to have been explored.

Why can't Alice get Bob's up-to-date encryption certificate
when she clicks on Bob's mailto URL?

Eric Norman

		"I may be just a butterfly,
		 but watch out if I flap my wings".

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 16 Feb 2003 10:23:11 +0100

>when she clicks on Bob's mailto URL?

Right on Eric!

I think the whole S/MIME-thing is pretty awkward to use for anybody.

I have toyed with the following idea for a while:  An SMTP-extension
holding an optional "encryption certificate lookup object" would allow a
more dynamic use of encryption.  This object should preferably be 
distributed as a part of a standard e-mail message, and hopefully
"land" in the address book completely automatically.  This extension
could also be supplied in an X.509 extension.

Phill: XKMS et. al. _do_ need an SMTP extension to become fully useful.

To go from a mailto directly, doesn't this require an enhanced mailto
URL unless mail clients are supposed to do XKMS/LDAP/CertStore
"fishing" using  DNS SRV-records etc?   I'm not so sure that such
"fishing" will prove to be very fruitful as it requires mail-providers
(e-mail domain owners) to maintain keys that often come from other
domains (TTP CAs).  That needs yet another special-purpose directory
"behind the scene" to work.    Since you anyway have to upgrade e-mail
and browser software on a regular basis due to viruses and "improvements", 
I can't see that an encrypted-mailto URL and an SMTP-extension would
be such major PITAs.   Existing systems would not break AFAIK.

All other suggestions also effectively require as a  minimum (apart from
possible CA changes), updated e-mail client software.

But is this a W3C, SMTP, S/MIME, or PKIX-issue?

Anders R