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

From: "Tom Gindin" <[email-masked]>
Date: Sun, 26 Jan 2003 12:13:02 -0500

In the LDAP PKI schema draft, section 7, the filter examples all deal
with matching certificates using serial number and issuer (1-5) or e-mail
address outside the DN (6).   These do involve relatively unusual matching
techniques (either component matching or PKI-specific matching rules) which
probably don't exist yet on most servers.  Also, this draft is now 7 months
old.
      These features are making some progress in LDAP, even if IMHO not
enough.  If the issuer has an LDAP directory which supports component
matching or the PKI matching rules, the problem we're left with in using
LDAP is still how to find the directory (or directories) with certificates
from a given issuer.

            Tom Gindin

"Blake Ramsdell" <[email-masked]>@mail.imc.org on 01/26/2003
03:50:20 AM

Sent by:    [email-masked]

To:    "'Richard Levitte - VMS Whacker'" <[email-masked]>
cc:    <[email-masked]>, <[email-masked]>,
       <[email-masked]>
Subject:    RE: X.500, LDAP Considered harmful Was: OCSP/LDAP

> -----Original Message-----
> From: Richard Levitte - VMS Whacker [mailto:[email-masked]]
> Sent: Sunday, January 26, 2003 12:10 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
>
> The real question is, if someone would need to, how do they search in
> your database?  What's the schema?  Is it standardised in any way, or
> does every database repository come with it's own, making it a
> configuration hell to make sure one can work with each of them?

They can't -- I'm just pointing out that since I'm not aware of any
standard, consistent way to present the queries I've listed to a
directory and get back the certificates I need, I gave up and made my
own proprietary solution.  I would absolutely love to have a published,
standard way of looking things up in a directory using these queries.
Once again, this could be something that I'm missing.

My point is not that relational databases are the salvation -- I
couldn't care less what you use on the back end.  I'm saying that in
order to find a certificate that matches a certain criteria, you should
be able to present the criteria, and get back the matching
certificate(s).  I think this is the essence of Peter's position also.

> As for me, I don't really care what the access method to repositories
> are, as long as there's a schema I can follow and the repository has
> usefull content (or referals to useful content).

I think we are on exactly the same page -- I don't care what the
protocol is, or what the schema is, or anything else -- I just want my
questions answered consistently.  I am still not convinced that LDAP
provides this today, or if sufficient efforts are underway to modify it
to support these types of queries.

Phill and Peter (and potentially others) have pointed out that LDAP has
a different design philosophy, and we're trying to make it do things
that it wasn't really designed to do.  We seem to be telling ourselves
that it's best to jam it into LDAP because "that's the standard", and
presumably we are deluded enough to believe that maintaining LDAP
compatibility is somehow virtuous.  The queries that have been presented
seem to be contrary to the normal operation and philosophy of LDAP
(specifically IssuerAndSerialNumber and SubjectKeyIdentifier).  If the
best answer is to modify or profile LDAP in some way, then I've got no
complaints -- I just want my queries answered.

Blake

---

From: Michael Ströder <[email-masked]>
Date: Sun, 26 Jan 2003 18:48:14 +0100

Tom Gindin wrote:
> If the issuer has an LDAP directory which supports component

Just for the records: Same problem with any kind of database.

Note that people solely posting SQL statements leave out this part (locate 
database and connect to the database) completely.

For LDAP there is a way using dc-style DNs and SRV RRs to locate the 
directory. Some people insist on dc-style DNs not widely used though (which 
is IMHO not true).

Ciao, Michael.

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Mon, 27 Jan 2003 00:09:58 +0100 (CET)

In message <[email-masked]> on Sun, 26 Jan 2003 18:48:14 +0100, Michael Ströder <[email-masked]> said:

michael> For LDAP there is a way using dc-style DNs and SRV RRs to
michael> locate the directory. Some people insist on dc-style DNs not
michael> widely used though (which is IMHO not true).

I'm not sure I agree with you (that it's not true).  I've seen masses
of certificates with "classic" DNs, and none in DC-style (although
there are enough people telling me they do exist for me to believe it
:-)).

However, that's beside the point.  Yes, of course, using DC-style DNs,
finding the repository is rather trivial.  But what about the rest of
the certs (the rather huge amount, I believe)?

I'm imagining it would be possible to have a network of interconnected
LDAP servers through referals, kind of the way DNS servers are
interconnected today, with the only difference that the "zones" would
be trees in the DN namespace.  I realise there would be difficulties
with this, but I don't see it as impossible (at least yet).
With such a network, one would need to know a few LDAP roots, and the
rest is about walking until there are no more answers or until one has
found what one was looking for...

The real problem with such a network would be searching for anything
else than DNs.  I've no idea if this is solvable (I may be missing
something in my LDAP education, for all I know), or if that just means
that the only way to search for a specific certificate in such a
network would be through subject or issuer+serialnumber, at least to
do things like validation.

Is this worth exploring or am I about to slam my head into a very
thick brick wall thinking about this (or both?)?

(note that some searches can still be made in basis of host names and
attributes on specific attributes.  Searching for an email address
(say [email-masked]) could start with finding out the LDAP repository
for random.tld, and then ask it directly)

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

---

From: Michael Ströder <[email-masked]>
Date: Mon, 27 Jan 2003 01:56:54 +0100

> there are enough people telling me they do exist for me to believe it

One could imagine other forms of using dc-style LDAP DNs and SRV RRs, e.g. 
look at the domain part of an e-mail address and query the SRV RR for it.

Send encrypted S/MIME e-mail to [email-masked]:

look up SRV RR for _ldap._tcp.stroeder.com
-> mydirectory.stroeder.com 389 0 0

Retrieve e.g. encryption cert for [email-masked]:

ldap://mydirectory.stroeder.com/dc=stroeder,dc=com?userCertificate?sub?(mail=[email-masked])
-> certificate

Note that in this example the subject DN in the cert can be anything.

> be trees in the DN namespace.

Requires a naming authority for X.521 names though.

> found what one was looking for...

Well, that was the basic idea of X.500...

> else than DNs.

???

Ciao, Michael.

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Mon, 27 Jan 2003 07:39:04 +0100 (CET)

In message <[email-masked]> on Mon, 27 Jan 2003 01:56:54 +0100, Michael Ströder <[email-masked]> said:

michael> > The real problem with such a network would be searching for anything
michael> > else than DNs.
michael> 
michael> ???

For example, say we want to find all records that match a certain
value with the attribute x509SubjectKeyIdentifier (from
draft-klasen-ldap-x509certificate-schema-01.txt), would that be
searchable in the imagined LDAP network?

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 27 Jan 2003 09:41:12 +0100

Michael,

>ldap://mydirectory.stroeder.com/dc=stroeder,dc=com?userCertificate?sub?(mail=[email-masked])

And the following would be the equivalent using this "other" system.

definitions in "stroeder.com" DNS:

   _certs._tcp   SRV   0  1  1  certstore.stroeder.com
   certstore      A     62.119.75.13
   certstore      TXT   https://certstore.stroeder.com/certapp

Note that _certs._tcp is just a handle, as the associated TXT-record
contains the actual URL

After DNS lookup you would query: 
"https://certstore.stroeder.com/certapp?email=[email-masked]"

Note: This is not a part of the HTTP CertStore draft, but it could be :-)

cheers,
Anders

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Mon, 27 Jan 2003 12:33:54 +0100 (CET)

michael> > I'm imagining it would be possible to have a network of interconnected
michael> > LDAP servers through referals, kind of the way DNS servers are
michael> > interconnected today, with the only difference that the "zones" would
michael> > be trees in the DN namespace.
michael> 
michael> Requires a naming authority for X.521 names though.

For the top level (whatever that would be), yes.  The rest of it would
be delegated to others (I'd assume they'd be called naming auhtorities
as well, right?).  We have that for DNS, I don't see that this would
be much different, except that the accepted names would be different
and probably broader (no, I haven't given that part much thought)...