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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 7 Feb 2003 06:39:58 -0800

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

There is no way you can modify the directory to do certificate
path discovery in a bridge CA without doing severe violence to 
the directory model

Furthermore future developments in the directory space are of
no relevance to PKI. We have already deployed XKMS. Regardless of 
whether one believes the future has angle brackets or OIDs the 
certificate repository of choice will be XKMS or OCSP/SCPV/DPVD 
[henceforth OCSPVD]

Been there, done that, moved on. If Steve Kent is upset that I
appear to be reinventing PKIX with angle brackets he can at least
have the consolation that as Oscar Wilde observed, to be reinvented 
with angle brackets is better than not being reinvented with angle 
brackets.

Whatever else UDDI might do it is not going to be a certificate 
repository.

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

I don't think your experience of the PKI field is sufficient to go 
arround patronising people. Even if you are an academic.

I think that it is you who are plain ignorant of the capabilities 
that PKI applications require of repositories, the trust structures
in use in commercial and government deployments and the role that
directories play.

To give an example, to discover your (somewhat sparse) publication 
record with its obsessive concentration on X.500 I did not consult 
a 'directory', I used a search engine called Google accessed by a
somewhat more successful protocol called HTTP that I helped to write.

If you had performed the same degree of rudimentary research yorself
you would have found the following article in the early hits:
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2879127,00.h
tml

		Phill

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 10 Feb 2003 16:06:25 +1300

=?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]> writes:

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

Good point.

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

It depends what your definition of "web services" is.  You're referring to
something like SOAP (let's call it "active HTTP" here).  Things like the HTTP
certstore interface are just a straight HTTP GET ("passive/pure HTTP"), which
fits the classic HTTP model, so you need to distinguish between these two
types.  As a security (rather than just PKI) person, I agree that active HTTP
is going to be a severe problem, and I'd never allow it onto any of my
networks or systems.

>If someone's to blame for lack of PKI acceptance it's this WG for not
>reaching consensus on very basic issues [...] and inventing new competing,
>even more complex standards all the time. 

Let me offer another view.  To paraphrase Steve Kent, "Let 10,000 RFCs bloom".
We have > 1,400 pages of PKIX RFCs and drafts already, the majority of which
are completely ignored outside the community that pushed for their adoption,
so eventually by a process of natural selection we'll see what survives.
Experience has shown that implementors will implement what they want to
implement and disregard the rest, and the results are remarkably consistent -
most implementations end up ignoring the same RFCs, and sections of RFCs,
without any overt advance agreement to do so, and regardless of whether it's
standards-track or nothing-track, MUST or MAY.

Here's how this would work:

  Make all PKIX RFCs (no exception) "Experimental".  After 18 months, try and
  find 3 independant implementations from competing vendors in different
  countries (to reduce false positives from things like 3 German vendors
  creating Sig*-compliant software).  If less than 3 implementations are
  found, leave it as "Experimental" (raining fire and brimstone on the RFC
  authors is left as an optional extra).  If >= 3 implementations that fit the
  bill are found, mark it "Informational".  If >= 5 implementations are found,
  with at least one being open-source (to reduce false positives where
  "implementations" consist of press releases from members of a vendor
  consortium), mark it "Standards-track".

That's at the macroscopic level.  At the microscopic level, do the same thing
with MAY, etc.

This will cause no change in the implementation status quo, but ensures that
the published RFCs at least contain some vague approximation to reality.

Peter.