Subject: RE: Microsoft and multi-valued RDNs (was: draft minutes)

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Jul 2003 14:59:30 -0400

Peter,

I think you are misinterpreting my position, somewhat :-)

We both agree that standards ought not embody undue complexity, 
features that nobody wants now and will never want, etc.

We disagree about where to draw the line re complexity, and about 
whether a willingness of users to distort their requirements to 
accommodate implementation limitations is a basis for changing 
standards.

Steve

P.S.  the good news is that our messages are getting shorter

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 1 Aug 2003 06:52:39 +1200

Stephen Kent <[email-masked]> writes:

>P.S. If one applied your model to TCP, we should not have checksums in that
>protocol. 

I think that's misrepresenting my position somewhat:

  My version of TCP would have a simple, straightforward, easy-to-get-right
  checksum (pretty much the same as what TCP does now), implementation notes
  and a rationale to guide implementors, and test vectors so people could
  check that their implementation is correct (see any RFC I've written).

  The PKIX version of TCP would have eight different checksums with two dozen
  sets of parameters.  Many checksum parameters are optional, but if you leave
  some of them out then things fail for no apparent reason.  Some are
  mandatory but have no discernable purpose, so people leave them out because
  it simplifies the implementation.  The mechanisms are identified by entries
  in an LDAP directory indexed with a multi-valued AVA in an RDN.  There are
  five different ways of applying the various checksums (one for each vendor
  that contributed to the standard), all incompatible and several mutually
  exclusive.  There's no explanation for any of the design features, so
  implementors have to guess at what they're supposed to do.  Everyone guesses
  differently.  There are no test vectors.  Nothing interoperates without
  extended, multi-iteration bakeoffs in which each side tries to match their
  guesses at what bits of the standard are supposed to mean with the other
  side's guesses at what bits of the standard are supposed to mean.  The best
  way to make sure things work is to buy everything from the same vendor, and
  even then things often only work under carefully-controlled lab conditions.

Now I'm being facetious there, but the scary thing is that I've described
fairly closely a number of PKIX RFCs (not to mention OSI before it).  I'll
omit RFC names, but anyone with any implementation experience will recognise
all of the above in various PKIX standards.  So on the one hand the scientist
part of me thinks that methodically repeating the failure of the OSI
standards-creation process in PKI is a good thing, since it's demonstrating
repeatability - OSI wasn't just a one-off thing, we can do it all again with
the same result (this is why I have a t-shirt that proclaims "PKI: The OSI of
a new generation").  On the other hand the engineering part of me, which just
wants to build something that works and is clean and elegant, is less than
thrilled with the prospect of PKI ending life as a 2-page historical footnote
in networking and security textbooks, as its predecessor for the most part
has.

Peter.