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

From: David Chadwick <[email-masked]>
Date: Thu, 06 Feb 2003 16:55:24 +0000

Phil

Bit late to come in on this discussion. Ironically the reason why is
because we are currently very busy modifying OpenLDAP to solve the very
sorts of problem identified by you below, and others (eg Peter G) in
later messages, namely, the ability to search in LDAP directories for
certificates that meet key,value pairs.

But actually your mail contains a lot of misguided comments as well, and
in some cases just plain ignorance of the facts about LDAP and X.500. It
also contains some quite comical bits e.g.

> the client wants to ask is 'what is the email address of
> [email-masked]' what the directory wants to be asked

Seems like the client already knows the answer!! So why ask for
something you already know? I guess it must have been a typo on your
part, but not quite sure what the mistake was.

But seriously, the problem LDAP had/still has, is that matching rules
for PKI certificates have never been defined/standardised, which means
that LDAP users can not search for certificates. Full stop. LDAP has
always been able to search for email addresses, indeed this was one of
the main reasons why many companies purchased LDAP directories in the
first place - to search for email addresses. Had matching rules for
certificates been defined by LDAP early on (they were for X.500, but
never mapped accross to LDAP) and implemented, then you would have been
able to do queries such as "find me the cert with key usage equals NR,
and subjectAltName email address is [email-masked]"; indeed any key,value
pair from any cert or CRL field would have been searchable.

However, to implement such matching rules in LDAP is complex. I and
Steven Legg have authored a couple of PKIX drafts which specified these
matching rules (for PKI and PMI). We also started to implement them.
Steven completed his in his X.500 based server, but we found it
difficult in a pure LDAP server (such as openLDAP), the difference being
that X.500 servers understood ASN.1 inherently, whereas LDAP tries to
minimise its understanding of ASN.1 as much as possible. And since certs
are completely ASN.1 based, they dont naturally fit with LDAP's way of
doing things.

Consequently we have now adopted the approach of Gietz and KLasen, and
are splitting the PKI certs and CRLs up into LDAP attributes, storing
the attributes in the conventional LDAP servers, and allowing the users
to search on these. And since these attributes use existing LDAP
matching rules and syntaxes, the conventional LDAP servers wont need
modifying. Our modifications to OpenLDAP will allow the modified
OpenLDAP server to sit in front of conventional corporate LDAP servers,
parse and split up the PKI certs, store them in the conventional LDAP
server as leaf entries, and then users will be able to search their
conventional LDAP servers for PKI certs. Meanwhile the CA will talk to
the modified OpenLDAP server as now, with no changes needed to it. There
will be some limitations in the searching capability, but it should
fulfil the vast majority of user requirements.

One final footnote. Just to show that I am not an "LDAP is the answer to
everything, now what is the question" type of person, I have a paper
being published in Comms of the ACM in April this year entitled
"Deficiencies in LDAP when used to support Public Key Infrastructures".
Watch out for it, and read it. It should help to dispell some of your
LDAP ignorance.

Answers to specific points you make below

David

"Hallam-Baker, Phillip" wrote:

>
> 
> The hierachical organization of the directory does not help
> the email application at all.

Not true at a corporate level. The DIT structure is irrelevant to the
email application since it typically searches the whole corporate
directory. At the internet level, the question becomes, how do I find
the right corporate directory to search. SRV records are solving this
one.

> The other practical problem with directories is that they will
> never reach beyond the enterprise firewall.

Whereas the web clearly has no problem at all with firewalls, since
everything is tunnelled through port 80, thereby blowing the concept of
a firewall entirely away. From a security perspective I would say that
LDAP is not a problem  for firewalls, but the web is. A plus point for
LDAP from a security perspective, is that directories actually use a
different port to the web, so administrators can control this traffic
more easily. And if one uses an LDAP application proxy in the firewall
as well, even better, you can have very tight control. (We built one
such proxy years ago and presented the results at 1997 NDSS in San
Diego)

>
>abstractions of sensitive
> data on external IT services whose principal purpose is providing
> indexing and searching functions.

Two points here. Firstly you are now acknowledging that LDAP servers DO
provide searching facilities, which you seemed to imply they did not do
earlier. Secondly, what is sensitive about a PUBLIC key certificate?
Perhaps the email address inside it?

regards

David

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 6 Feb 2003 21:04:22 +0100

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.  If you go to most major corporation (in
contrast to academia) and check their home-pages for personal
e-mail addresses, you will have to look very hard find anything,
and _never_ a view allowing outsiders to search for employees.
Authenticating to directories become ridiculous when organizations
have hundreds of thousands of employees are "authorized".

How many encrypted messages did you receive lately?

Anders

---

From: Michael Ströder <[email-masked]>
Date: Thu, 06 Feb 2003 23:07:38 +0100

Anders Rundgren wrote:
> 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.

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

And I also agree with David that web services just circumvents firewalls by 
simple HTTP tunneling. That's not a solution, it's a real security risk 
making content filtering and very complex proxying necessary in the long 
run. Web services' promoters simply keep quite about that and security 
people are still too busy repairing the rest of the brave new web world, the 
weird mess we already have.
</rant>

>  If you go to most major corporation (in
> e-mail addresses, you will have to look very hard find anything

Yes, this is the privacy problem. So what? It's completely independent of 
the X.500 model and LDAP. Is that news to you? This is a really hard issue 
to solve even *within* large companies no matter which technology you're 
using. There's no general solution and I doubt there will be one in a 
forseeable future.

> How many encrypted messages did you receive lately?

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

If someone's to blame for lack of PKI acceptance it's this WG for not 
reaching consensus on very basic issues (feel free to check the mailing list 
archive *excluding* the dumb X.500 bashing of last three months) and 
inventing new competing, even more complex standards all the time. 
Implementors simply can't follow reading the relevant RFCs to determine what 
to implement and what to leave aside. Not to speak of ambigous wording 
leading to many broken implementations.

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

Ciao, Michael.

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Thu, 06 Feb 2003 23:45:31 +0100 (CET)

In message <01c301c2ce1a$f2146690$0500a8c0@arport> on Thu, 6 Feb 2003 21:04:22 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> But the _real_ problem with the X.500 model is that
anders.rundgren> it builds on the assumption that organizations want
anders.rundgren> to publish information for others to search.  If you
anders.rundgren> go to most major corporation (in contrast to
anders.rundgren> academia) and check their home-pages for personal
anders.rundgren> e-mail addresses, you will have to look very hard
anders.rundgren> find anything, and _never_ a view allowing outsiders
anders.rundgren> to search for employees.

For those organizations, it would seem obvious that you'll get
whatever certificate you may need when someone from said corporation
gets in touch with you, not the other way around.

anders.rundgren> How many encrypted messages did you receive lately?

As I recall, that shouldn't be a problem in this context.  Maybe you
meant "signed" rather than "encrypted", and in that case (IIRC),
you'll usually get the signators certificate in the same mail.

As far as I'm concerned, there's a different type of data that's
rather crucial to have more or less publically available: the CA
certificates, and I'm sure most organizations wouldn't avoid having
those publically available, or?

It's pretty late, and I suffer a bit from lack of sleep, so if the
above didn't make sense, I'll probably have to reiterate my comment
tomorrow...

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"