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

From: [email-masked] (Peter Gutmann)
Date: Mon, 28 Jul 2003 20:25:47 +1200

Stephen Kent <[email-masked]> writes:

>I appreciate the clarification, but I am appalled by the suggestion that
>people should construct ungainly CNs that will be hard for users to parse, or
>that LDAP schema should be skewed to accommodate this lack of standards
>compliance.

PKIX, meet the real world.

Actually I'd like to offer a small soapbox here on the out-of-touch-with-
reality nature of many PKI-related RFCs, and the deleterious side-effects that
this has when the RFC is applied in practice.  For example there's an EDI
messaging standard that had to do X (and also Y and Z, none of them related to
verifying sigs after the cert has expired as per the recent thread), so they
went to the appropriate RFCs, picked the way they wanted to do things, and
wrote it into their standard.  Since security always gets bolted on as an
afterthought, the rest of the standard was in use for a year or two before
anyone got around to looking at the security parts of it.  At that point they
discovered that nothing in existence implemented what they required (poor
guys, they thought that MUST in the RFC implied that it'd be supported), and
no vendor was interested in supporting it [0].

This situation is unfortunately all too common, with users (and in this case
the WG chair) discovering that some feature discussed in an RFC as if it were
a hard fact exists only in the imagination of the RFC author.  What's more
problematic is the case of RFC A relying on an imaginary feature of RFC B
which in turn relies on an imaginary feature of RFC C.  This is why, in stuff
I write, I include extensive implementation notes with caveats such as "The
standard says MUST X, but in practice no-one does it that way, so be prepared
to encounter data which doesn't do X at all".

A few years ago I started making a list of features in PKI RFCs, rated from
1-5 in terms of support in implementations, where 1 means "you can rely on it
being present" and 5 means "don't bother", the idea being that users could
consult it to see whether the feature they wanted was going to be available in
the real world.  I abandoned it after a while because (a) I didn't think I'd
make many friends pointing out how little of what was in the RFCs was actually
supported in practice and (b) there was a kind of geometric growth of features
as you went further along the scale (i.e. from 1 to 5).

So to sum up I really wish PKIX would at least make some attempt to
approximate the real world.  SSH for example has just had a poll of
implementors/implementations to check for how to handle a new feature being
added, with the primary goal being existing support for it and compatibility
with current implementations.  The PKIX approach in contrast seems to be to
construct cloud castles, declare the problem solved, and then wonder why
nothing does what the RFC says.

Peter.

[0] Actually I believe that there exists a single experimental/reference
    implemetation that does it, but I'm not sure who uses it in practice.

---

From: "todd glassey" <[email-masked]>
Date: Mon, 28 Jul 2003 06:33:57 -0700

Peter - this is why so much of what PKIX did was not appropriate for the
IETF but belonged by pure definition in the IRTF, but then the management
team wouldn't of had the empire they have now to manage... PKIX is then a
fiefdom and has never been anything else.

So lets ask the management team the really big questions

    1)    How many years has PKIX existed

    2)    How many RFC's has it produced that have made it to Standards
Status

    3)    At what cost and to the expense of how many participants and their
sponsors...

Maybe its time to do the nasty and make PKIX a financial operations model so
we can really see what is what here.

Todd Glassey

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Jul 2003 10:58:11 -0400

>we can really see what is what here.

PKIX, like all other IETF WGs, is a volunteer activity. Nobody is 
required to participate. Only on ToddLand would a "financial 
operations model" make any sense for any of the IETF WGs.

Talk of being out of touch with reality ...

Steve