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

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

On Mon, 27 Jan 2003 11:10:39 +1000, Dean Povey wrote: 

>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

Er, I had completely forgotten about Peter's "Certificate Store Access via
HTTP" draft which does pretty much exactly this. So, yes Peter, my point
exactly :-).

Mea Culpa.
-- 
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

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 27 Jan 2003 16:59:28 +1300

"Blake Ramsdell" <[email-masked]> writes:

>You're missing Peter's point here -- the SELECT is not necessarily meant to
>be SQL, it's meant to convey that the single useful problem that a
>certificate database (be it X.500, SQL, whatever) solves is to return some
>number of certificates that exactly matches some search criteria.

This was exactly my point.  The process I went through in my ACSAC paper 
(http://www.cryptoapps.com/~peter/09a_cert_store.pdf if you want a copy) was:

  - Define the problem
  - Examine possible solutions
  - Take the best solution to the problem
  - Implement it and report results

OK, now that's "Scientific Method 101", but I mention it in order to contrast
the approach that lead to LDAP:

  - Decide on a way to do things
  - Wait for people to figure out how to make it happen.  Forever, if
    necessary.

Again, the exact details of the process are given in the ACSAC paper,
including various supplementary considerations like security and
accountability issues.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 27 Jan 2003 17:24:00 +1300

=?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]> writes:
>Blake Ramsdell wrote:
>>You're missing Peter's point here
>
>I don't.

Yes you do.  Trust me, as the person who wrote the post, you're missing its
point completely :-).  My point was that examining the problem that needs
solving, seeing that it's an application of {key,value} lookup (which I
expressed in SQL-like notation because it's the natural way to express these
things), and then finding the best technology to do this, is the way to go
forward.

>Maybe the use-cases should be cleanly modeled.

They are (see my ACSAC paper, which goes into a lot more detail, including
things like real-world deployment issues), and my earlier post.  To quote the
earlier rant:

  cryptlib supports any kind of cert storage mechanism that you can think of
  (flat files, DBMS, Berkeley DB, LDAP, PGP keyrings, PKCS #11, etc etc etc,
  including some semi-proprietary backends like named segments in flash
  memory).  The most frequently-used one is the DBMS interface (that is, the
  {key,value} lookup model), although there's a fair bit of usage of LDAP as
  well.  In terms of difficulty encountered in using it, no-one has ever,
  *ever* reported a single problem with the {key,value} interface (beyond
  compiling/linking, e.g. using an old version of the Oracle libs or
  something).  In contrast LDAP is the most problematic cert-storage interface
  there is, with an almost continuous flow of questions about the magic
  formulae needed to locate a cert (see above), problems with storing certs
  when the DN doesn't agree with the directory schema, or schema A doesn't
  agree with schema B, and every other LDAP problem that people on this list
  are all too familiar with.  Some people never get cert storage with LDAP
  working at all, and give up.
  
  This is real-world experience talking here folks, from a worldwide user
  base: {key,value} lookup works with zero problems, LDAP has endless
  problems.  I don't care about database or X.500 ideology or theology or
  proctology, the fact is that in practice one approach works and the other
  doesn't, and no amount of whining about "Well in theory we could maybe make
  it work some of the time, and here's an imaginary problem where yours won't
  work and ours will" is going to change that.

Peter.

---

From: [email-masked]
Date: Sun, 26 Jan 2003 22:46:09 -0700

my original suggestion for SSL "certificates" stored in DNS .... was to
just use signed something slightly more than signed public keys. as opposed
to full x.509 asn.1 encoded certificates ... and piggyback it with the
ip-address response. that easily fits within the 512-byte limit. if you
want additional information .... you do the more detailed queries for the
additional information associated with a domain name ... however you don't
get all the additional information that might be bound to a domain name
unless you expressly ask for it.

to some extent because certificates bind information statically at some
point in the past with possibly no real anticipation for all the uses it
might be put ... there is a tendency to try and pack as much as possible
in the static binding. going to a much more dynamic infrastructure would
mitigate significantly trying to maximize value of a static information
certificate binding (and thereby creating worst case payload bloat for all
cases).

nslookup example  ...

> help
Commands:   (identifiers are shown in uppercase, [] means optional)
NAME            - print info about the host/domain NAME using default
server
NAME1 NAME2     - as above, but use NAME2 as server
help or ?       - print info on common commands
set OPTION      - set an option
    all                 - print options, current server and host
    [no]debug           - print debugging information
    [no]d2              - print exhaustive debugging information
    [no]defname         - append domain name to each query
    [no]recurse         - ask for recursive answer to query
    [no]search          - use domain search list
    [no]vc              - always use a virtual circuit
    domain=NAME         - set default domain name to NAME
    srchlist=N1[/N2/.../N6] - set domain to N1 and search list to N1,N2,
etc.
    root=NAME           - set root server to NAME
    retry=X             - set number of retries to X
    timeout=X           - set initial time-out interval to X seconds
    type=X              - set query type (ex.
A,ANY,CNAME,MX,NS,PTR,SOA,SRV)
    querytype=X         - same as type
    class=X             - set query class (ex. IN (Internet), ANY)
    [no]msxfr           - use MS fast zone transfer
    ixfrver=X           - current version to use in IXFR transfer request
server NAME     - set default server to NAME, using current default server
lserver NAME    - set default server to NAME, using initial server
finger [USER]   - finger the optional NAME at the current default host
root            - set current default server to the root
ls [opt] DOMAIN [> FILE] - list addresses in DOMAIN (optional: output to
FILE)
    -a          -  list canonical names and aliases
    -d          -  list all records
    -t TYPE     -  list records of the given type (e.g. A,CNAME,MX,NS,PTR
etc.)
view FILE           - sort an 'ls' output file and view it with pg

============================

also some discussion in rfc2151/fyi30, Internet & TCP/IP Tools & Utilities,
Section 3. Finding Information About Internet Hosts and Domains).
http://www.garlic.com/~lynn/rfcidx7.htm#2151

2151
A Primer On Internet and TCP/IP Tools and Utilities, Kessler G., Shepard
S., 1997/06/10 (52pp) (.txt=114130) (FYI-30) (Obsoletes 1739)

from above:

One additional query is shown in the dialogue below. NSLOOKUP examines
information that is stored by the DNS. The default NSLOOKUP queries examine
basic address records (called "A records") to reconcile the host name and
IP address, although other information is also available. In the final
query below, for example, the user wants to know where electronic mail
addressed to the hill.com domain
actually gets delivered, since hill.com is not the true name of an actual
host. This is accomplished by changing the query type to look for mail
exchange (MX) records by issuing a set type command (which must be in lower
case). The query shows that mail addressed to hill.com is actually sent to
a mail server called mail.hill.com. If that system is not available, mail
delivery will be attempted to first mailme.hill.com and then to
netcomsv.netcom.com; the order of these attempts is controlled by the
"preference" value. This query also returns the name of the domain's name
servers and all associated IP addresses.

The DNS is beyond the scope of this introduction, although more information
about the concepts and structure of the DNS can be found in STD 13/RFC 1034
[19], RFC 1591 [21], and Kessler [16]. The help command can be issued at
the program prompt for information about NSLOOKUP's more advanced commands.

===

http://www.garlic.com/~lynn/rfcidx3.htm#1035

1035 S
Domain names - implementation and specification, Mockapetris P., 1987/11/01
(55pp) (.txt=122549) (STD-13) (Updated by 1101, 1183, 1876, 1982, 1995,
1996, 2136, 2181, 2308, 2535, 2845, 3425) (DOMAIN)

http://www.garlic.com/~lynn/rfcidx5.htm#1591

1591
Domain Name System Structure and Delegation, Postel J., 1994/03/03 (7pp)
(.txt=16481)

somewhat related discussions:
http://www.garlic.com/~lynn/aepay10.htm#78 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#79 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#80 Invisible Ink, E-signatures slow
to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow
to broadly catch on (addenda)

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

[email-masked] on 1/26/2003 6:10 pm wrote:

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.

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 27 Jan 2003 19:25:14 +1300

"Blake Ramsdell" <[email-masked]> writes:

>But I'm not sure we can say with a straight face that this isn't beating LDAP
>with a hammer to make it more like we want it.

I've just looked at draft-klasen-ldap-x509certificate-schema-01 and it seems
to be an RFC describing how to make an LDAP directory act like an RDBMS.  So
for example:

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 SELECT certificate WHERE sKID = ..., and so on.

I don't know whether I should laugh or cry.

Peter.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Jan 2003 07:29:06 -0800

> You're missing Peter's point here -- the SELECT is not 
> necessarily meant
> to be SQL, 

This is the crux of the matter. The question the app wants
to ask is:

What key should I use to talk protocol X to identifier Y?

The simple fact is that it is much easier to implement this 
query, the one the app actually cares about than all the X.500
and LDAP mush.

Common name, Distingushed name, first name, last name SHOULD NOT
be searchable fields. There is no utility in making them
searchable. 

> For eight years I've been working with S/MIME, X.509 and related
> standards, and with the exception of adding SubjectKeyIdentifier, the
> criteria I've wanted to search on have not changed.  And I 
> still cannot
> do those searches today with anything other than my own database.

Try XKMS.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Jan 2003 08:35:01 -0800

It will be once we drive a steak through the heart of
the Directory vampires.

	Phill

> -----Original Message-----
> From: Michael Ströder [mailto:[email-masked]]
> Sent: Monday, January 27, 2003 11:29 AM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]
> Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP
> 
> 
> Hallam-Baker, Phillip wrote:
> > 
> > They have got their fangs into PKI because they believe
> > that we are their killer application.
> 
> Uuh, anyone here still believe that PKI is a killer application?
> 
> Ciao, Michael.
>