Strength in Complexity?

[Peter Gutmann]

"Perry E. Metzger" <perry at piermont.com> writes:
>pgut001 at cs.auckland.ac.nz (Peter Gutmann) writes:
>> (Actually even that doesn't really explain something like IKE... :-).
>
>Having been peripherally involved in the causation change for IKE, let me
>confess that it was caused by human stupidity destroying the alternatives.

The reason why I was using IKE as an example is that it's a lot better-known 
than PKI.  That is, most people on the list know in general terms that PKI is 
a mess, but probably only a few who have had to read and implement some of the 
RFCs (http://www.ietf.org/html.charters/pkix-charter.html) know just how 
incredibly *bad* it really is - it's a perpetual motion machine [0] of 
incomprehensible, contradictory, unimplementable, and often entirely 
nonsensical requirements [1] for which, once you get beyond the simplest 
mechanisms, the behaviour of any one implementation is more or less arbitrary 
as authors have to take guesses at what the authors of the spec (and the 15 
other interfering specs in the same field) might have been thinking when they 
wrote it.  And unlike the IKE bakeoffs there's no interop testing, so there's 
no way to tell whether any two implementations will ever treat the same 
(nontrivial) cert in the same manner.  Unless you've had to implement PKI 
stuff it's difficult to convey the true horror of trying to make sense of 
those specs, which is why I've been using IKE as a better-known example.  If 
you're an IKE fan then mentally replace all occurrences with "PKI" :-).

Peter.

[0] Don't like some way of doing things?  Wait six months, three more RFCs
    will be along to provide different (generally incompatible)
    interpretations.
[1] Show of hands, how many people here not directly involved with X.509 work
    knew that the spec required that all extensions in CA root certificates
    ("trust anchors" in recent X.509 jargon) be ignored by an implementation?
    So if you put in name constraints, key usage constraints, a policy
    identifier, etc, then a conforming implementation is supposed to look at
    them, throw them away, and proceed as if they weren't there?  More 
    amusingly, if you mark a non-CA cert as trusted then the requirement to
    ignore the extensions means that it can act as a trusted CA root 
    certificate (with the same rights as, say, Verisign's root certs)
    since the "not-a-CA" flags has to be ignored.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com