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

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

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

Yes, that is why I have been arguing that the certificates 
should be stored in an XKMS repository that is linked to
the DNS and not in the DNS itself.

If you want to restrict yourself to the PKIX world you could
link a DPD/DPV server to the DNS in the same way, with a few
minimal changes to the protocol.

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

Actually that no longer holds with EDNS, but you still don't
want to join DNS and PKI at the hip except possibly for the case
of IPSEC keys.

Trying to make DNS work like a PKI has the same problem as
trying to work in the X.500 straightjacket. You have to deal
with lots of legacy stuff that does nothing but get in the 
way.

People go on and on about not re-inventing the wheel. However 
the problems of trying to re-use technology in inappropriate 
contexts causes far more harm in the long run. PKI has failled
to get value out of X.500 and LDAP for ten years, the answer
to this problem is not to go running off to misuse DNS in the
same way.

The SRV link does the job nicely.

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

This is almost what XKMS does. The one slight difference being
that we use XML and SOAP rather than the query syntax.

		Phill

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 28 Jan 2003 09:33:21 +0100

Going back to the subject line's "harmful", I have some
serious doubts regarding the original intent ("application"):

Except for path-validation, the other major reason of retrieving
somebody's certificate is for sending encrypted messages.

This assumes that privacy both with respect to the individual,
and to the organization that the individual may belong to is of
secondary importance.

That lookup and retrieval systems often require authentication
is not much of a blessing as this in a open Internet environment
makes "user" administration a true nightmare.

It would indeed have been wonderful to be able to search a
public directory where you could with the help of various
attributes, even be able to separate the "real" Slim Shady
from the "other" Slim Shady.  Unfortunately, both Slim Shadys
feel less enthusiastic about this...

The only really useful "open" lookup I can think of, particularly
in conjunction with DNS, is for retrieving keys to DOMSEC,
IPSEC, and similar non-personal communication.

Summary:
CIOs thinking about aligning their directory structures to
other organizations' should take a deep breath and put these
questions on the table: How wide is our circle of "allies"?
Will it stay like this for a considerable time?  How are we
going to manage possible temporary associations?  And if
we only have a relation between "departments"?

Anders R