Subject: Re: OCSP I-Ds going forward

From: [email-masked] (Peter Gutmann)
Date: Thu, 28 Nov 2002 18:44:43 +1300 (NZDT)

"David P. Kemp" <[email-masked]> writes:

>You are, of course, correct.  I'm just surprised to see an ideological
>principle being articulated by a pragmatist such as yourself.

It's being realistic: If you're working with an ideology that requires that
all DNs be unique or your ideology collapses, you have to live with that, in
the same manner that it's not a good idea to have the pope declare infallibly
(ex cathedra) that the world is flat without causing problems for your
religion.

That doesn't mean I agree with it.  I've seen DNs as a lost cause since day
one, and my code has always used a certID (code-internal name for an SHA-1
hash of the cert) to uniquely ID certs when it needs that.  It's a compact,
fixed-length, easy-to-use ID which just works.  I don't care what's in the
cert, the certID will manage it.

I also put an extension into all PKI protocol messages I generate which
contains the certID, and my code will ignore whatever other ID may be present
if it finds a certID in a message.  This is both a strength and a weakness:

Advantage: It just works, no matter what sort of junk is in the cert (I could
  do OCSP queries on SPKI certs if necessary without batting an eyelid).  This
  is great, since you can get any two cryptlib implementations to work out-of-
  the-box without having to fiddle with DN formats and who knows what else.
  There's at least one case (probably more) where my code ended up being used
  solely because they couldn't get another implementation to work - I don't
  know what the problem was, broken DNs or something, they didn't know enough
  about PKI to diagnose the problem themselves, and I wasn't going to go out
  of my way to fix someone else's code :-).

Disadvantage: It stops working when interoperating (or not, in this case) with
  sites using broken code or doing weird things with certs.  The standard
  response is that they user doesn't care whether the software they're using
  is non-standards-compliant (for example getting the OCSPv1 ID wrong, which
  isn't that rare), they just want it to work.  The end result is that they
  deploy the broken stuff on both sides of the link, and don't care about
  standards-compliance or interoperability, as long as it works for them.
  
  This is not a good situation to put users in, unless you're the vendor of
  the broken software.

>One problem, even within a centrally-administered PKI such as the DoD's, is
>that there are advocates for putting local (non-unique) distinguished names
>in certificates.

That's the approach I advocated (without claiming to have invented it, BTW :-)
in things like "PKI: It's not dead, just resting" - the name only has to be
meaningful within the COI to be useful.

>I can think of only one way that that might happen: require every CA that
>wants to join the "Unbroken PKI" to have an RFC 2247 (DC) distinguished name
>instead of the old C=x, O=y.
>
>Do you think that's likely to happen?

Nope (I don't recall ever talking to anyone other than PKI people who even
know DCs exist).

>Do you think there's a different coordination mechanism that's likely to
>happen?

Nope.

>Do you really think OCSP (and S/MIME) should just shrug their shoulders and
>say "not my problem"?

I'll answer that one indirectly:

* X.500 theology requires that DNs be unique.  If you want to live within the
  theology (for example using CRLs or feeding your OCSP responder with CRLs,
  which assume unique DNs to ID CAs), you need to play by the X.500 rules.

* If you don't want to play by the rules, you have to make some concessions,
  like using the certID to ID certs.  In other words if you're using non-
  unique DNs, you can't use CRLs which assume DNs are unique.  It's as simple
  as that.

You can't have your cake and eat it too.

Peter.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 28 Nov 2002 11:32:39 +0100

> Nope (I don't recall ever talking to anyone other than PKI people who even

Peter, I disagree with your opinion about acceptance of DC-style DNs. Usage 
of DNs according to RFC 2247 is getting very common in today's LDAP deployment.

The main problem with PKI deployment is that most PKI-enabled software does 
not support this kind of DNs.

Ciao, Michael.