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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 10 Feb 2003 08:27:33 -0800

> Anders Rundgren wrote:
> > But the _real_ problem with the X.500 model is that it builds
> > on the assumption that organizations want to publish information
> > for others to search.
> 
> Again: This is not a specific problem with the X.500 model. 
> It's a general 
> problem with certificate retrieval across organizational boundaries.

I don't see this as an objection to the X.500/LDAP architecture.
However it is a severe restriction on deployment.

Since the argument for reuse of LDAP is that it is deployed and
the excuse for reuse of X.500 is that it is going to be deployed
the fact that enterprises will not allow public access to anything
that looks like a directory is very relevant.

Not making your directory world readable is probably more important
as an enterprise security measure than firewall deployment.

> <rant>
> Using a 'web service' (whatever we might agree in the future 
> if ever on what 
> that really is) will just migrate the very same problems to 
> another service. 

First off, there is considerable agreement on the definition
of Web services. They are machine/machine protocols that are
encapsulated in SOAP messaging.

Note that there is no requirement to run over HTTP. I think that
in the long run we will move to DIME or something similar.

> That's what folks should understand *before* trying to solve 
> problems by 
> defining yet another standard with yet another buzz-word.

Take a look at the XKMS specs. The problem is really well 
understood at this point.

> And I also agree with David that web services just 
> circumvents firewalls by simple HTTP tunneling. 

That is a misconception, although several folk like Bruce
the sage of Minnessota have been plugging away at it.

First off Web Services need not be layered on HTTP. In 
fact DIME is a much cleaner interface. But HTTP has some
near term advantages.

Secondly a large part of the Web Services architecture is
all about how to route messages through firewalls, the
visibility that messages must have, etc. etc.

There is an assumption that the firewall does somewhat more
than simply block certain ports.

> PKI acceptance is yet another issue independent of X.500 directories.

No, the X.500 linkage is the single biggest barrier. It has
led to more failed PKI deployments in my experience than any
other.

The customers have wanted to deploy a PKI, they are captured by
a directory vendor. They spend three years arguing over theri DIT
instead and erroneously conclude that PKI is hard to deply.

For PKI deployment to succeed you have to take X.500 and LDAP 
deployment out of the critical path.

> If someone's to blame for lack of PKI acceptance it's this WG for not 
> reaching consensus on very basic issues 

No, that is not a factor in PKI deployment. This list is no longer
a factor in the development of the PKI world.

The basic certificate standards are already deployed in Windows 
2000, Java and the rest. The job of this group is to document the
reality that has been created. This group cannot influence changes
in the PKI infrastructure, that has already happened.

This by the way is the IETF way. HTTP was only standardized some 
six years after the protocol was ubiquitous.

> (feel free to check  the mailing list 
> archive *excluding* the dumb X.500 bashing of last three months) and 

Was there a previous X.500 bashing thread? I don't think so.

We have only been on this thread since the new year.

> And no, the problems will not automagically be solved by XML, 
> XKMS, <your 
> favourite buzz-words here...>.

The XML syntax is neither here nor there. I used it simply because 
if I ask an engineer to learn ASN.1 they start preparing their resume,
engineers ask me if they can learn XML.

Whether or not XML is actually superior it has won by any empirical
standard. Choosing to use ASN.1 at this point is like choosing to
use EBSDIC instead of ASCII. 

I hope that we put rather more into the design of XKMS than simply
rehashing PKIX in XML. In fact that was the one thing that the
original charter did not allow us to do.

		Phill

---

From: Peter Gietz <[email-masked]>
Date: Fri, 14 Feb 2003 15:32:54 +0100

Hi all,

Sorry to join this thread so late.

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.

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. That might be of help to 
evaluate the different proposals. May be we should write an I-D on this. 
If others also volunteer I would be willing to put effort into such an 
activity. Peter Gutman's document on "A Reliable, Scalable 
General-purpose Certificate Store" would definitely provide some usefull 
input for such a document.

As to LDAP/X.500:

Michael has shown that most arguments against LDAP/X.500, e.g. privacy 
issues, organisations not willing to publish information about their 
employess, etc. also hold true for the other technologies.

I vote for LDAP, since it provides an established network protocol and 
data modell that is flexible and comes along with important features 
like authentication, replication and especially distribution of the 
database. LDAP BTW does not need PKI as killerapp, it is being used as 
corporate directory since a long time with a lot of different usages.

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 (inside an organisational 
structure together with white pages and yelow pages information or in a 
cert only repository). It also solves the problem of multiple certs of a 
user.

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.

David Chadwick's work on an LDAP server that sort of translates between 
the classical LDAP certificate storage in attributes like 
userCertificate and our model makes no changes necessary for current 
clients. But even without such an intermediate server, client 
modifications would be rather simple (changing the search filters).

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, e.g. you 
could also want to get back the cert's subject, its issuer, its valdity, 
etc. instead of the cert. BTW in that example it would be fairly safe to 
do without the "objectClass=x509certificate" bit. Anyway I don't see 
enough difference between the ldap URL and your http URL to get so high 
emotions.

In combination with David's new draft on CRLs, an OCSP server can be 
implemented on top of an LDAP server very easily (to come back to the 
original thread). Your Certstore via an LDAP2Web gateway? again no 
problem. This is not like your "putting a pea on a fork example" it is 
more about management efficiancy (one data store and multiple usages for 
it).

One last comment:

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

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. X.509 people rediscovered the X.500 model from 
which X.509 once originated. And I am quite confident that threads like 
this one will not change this.

Cheers,

Peter Gi.

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________