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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 24 Jan 2003 14:42:46 -0800

The real question is why it has taken the industry so long to
ask this question.

There are two types of information retrieval system that
have utility. Systems designed for use by humans and systems
designed for use by machines. The Web is an example of the
former, the DNS an example of the latter.

The problem with X.500 and its descendants is that they try
to be both at the same time and end up succeeding at neither.

First let us dispense with the system designed for use by humans.
We have a system, it is called the Web, everyone else lost, get 
over it.

When a directory is used it is being used by an application such 
as email to service an actual transaction. My outlook client
is querying the GAL in response to my attempts to compose email.

Consider the question that an email client is going to ask
a certificate repository. It is not going to ask for 'C=US
O=Hopeless ...'. The question is going to be asked in the context
of a specific problem that a specific application needs to
answer. That specific context is going to be an email address
and an email application such as S/MIME or PGP.

The hierachical organization of the directory does not help
the email application at all. In fact it is exactly the type
of annoyance that led for the need for HTTP over FTP. The 
application knows exactly the question it wants to answer 
but that is not the question the directory will accept, instead
we have to pay proper homage to the X.500 data model by navigating
arround it a bit.

The directory does not want to answer the question at all, instead
it wants to play 20 questions with the client. So while what 
the client wants to ask is 'what is the email address of
[email-masked]' what the directory wants to be asked
is 'do you have any american', yes, 'do you have any americans
working for first data', 'do you have any...' and so on.

The other practical problem with directories is that they will
never reach beyond the enterprise firewall. Except in the Federal
Government enterprises guard their org charts as company
confidential information. The Federal govt would do the same but
the head hunters thought up a ruse called FOIA.

At one time there was a theory called 'border directories'. Under
this theory, organizations would decant the certificate information
from their PKI directory and publish it outside the firewall. The
teensy problems with this theory being that first it required a
duplicate directory system which was not cheap and secondly CIOs
still get nervous about putting even abstractions of sensitive
data on external IT services whose principal purpose is providing 
indexing and searching functions.

Directories have failed to move beyond the firewall, so why are
they still being plugged as the solution for PKI? The answer if
you have not worked it out yet is that the objective here is to 
deploy  X.500 which in turn will enable the transition to OSI to 
finaly begin. The idea is that PKI is to be the killer app for
X.500 even though only thing this scheme has killed to date is
plenty of attempts at PKI deployments.

What is needed is an infrastructure that is linked to the DNS
system, a DNS linked PKI. The lookups supported should be in the
terms the applications care about. For example the UseKeyWith
semantics of XKMS. Similar semantics will no doubt be proposed
for supported by the PKIX equivalent DPV specification.

The justification for introducing directory systems was based on
a falacy, namely that using email addresses was somehow less
secure than using real world names. This is clearly not the case.
I may or may not be the only Phillip Hallam-Baker at VeriSign,
however I will certainly be the only [email-masked] no matter
who they hire in the future. Equally some of the female employees
have changed their surnames several times over the past 5 years
but their old email addresses still work.

Trying to 'make it easy' has been the source of more security
problems than it could possibly have corrected. Only yesterday
I received a message sent to [email-masked] because
someone had tried to send an email to Sam and the auto-expansion
had kicked in and gone off searching the GAL when it had no business
to.

In conclusion it is time for the PKI world to seriously consider 
whether X.500 and LDAP provide the right certificate repository
structure for PKI. For myself I consider them harmful.

		Phill
 
> At 06:52 PM 1/8/2003 +1300, Peter Gutmann wrote:
> 
> >Other person: "Why is X.500 so special?  Why is no-one else 
> doing this?"
> >
> >Me: "Get your favourite book on database technology and look up
> >      'Hierarchical databases'".
> >
> >[Time passes]
> >
> >Other person: "I looked in several books.  Many didn't 
> mention it at all,
> >                and one had a half-page historical note 
> saying it's something
> >                that was obsoleted by better technology more 
> than two decades
> >                ago".
> >
> >Me: "Exactly".
> 
> 
> Heh.  Actually, hierarchical databases can be superlative to 
> most all other 
> technologies, when one has a static taxonomy to support.  Trying to 
> represent (no less manage) a dynamically changing global 
> namespace with 
> scores of independent geopolitical naming authorities with a 
> hierarchical 
> database is rather ... ridiculous. :)
> 
> Cheers!  ____tony____
>

---

From: Dean Povey <[email-masked]>
Date: Mon, 27 Jan 2003 11:10:39 +1000

>for supported by the PKIX equivalent DPV specification.

While I don't disagree with your argument about X.500, there are real 
practical problems with using DNS for storing Certificates (if that is 
indeed what you mean by a DNS linked PKI).  RFC2538 notwithstanding, the 
problem is that storing large objects like Certificates in DNS generally 
necessitates TCP transfers as they will exceed the magic 512 byte limit 
at which servers will generally truncate packets. Using TCP means that DNS 
which is a generally stateless service, now has to keep connection state 
with clients opening up all sorts of room for DOS and simple performance 
problems with what is a critical service. In addition, it is common for 
admins to configure firewalls so that TCP DNS is filtered to prevent zone 
transfers.

That said, I think the problem is largely solved by storing certs on a 
HTTP server, indexed on some interesting attributes that can be specified 
using standard HTTP GET uri?attr=value syntax.  With redirects this can 
easily link directories for scalability and decentralised management.  All 
that is required is to standardize the attributes and the replies.  The 
major benefit is that this can be very easily supported in applications.  
This was more or less the approach taken with PGP Keyservers, which have 
proved to be very successful.
-- 
Dean Povey,             |em: [email-masked]|Security for Network Devices
Wedgetail Communications|ph:  +61 7 3023 5139   |uPKI: Embedded/C PKI
Level 14, 388 Queen St, |fax: +61 7 3023 5199   |uSSL: Embedded/C SSL
Brisbane, Australia     |www: www.wedgetail.com |JCSI: Java security