"Perry E. Metzger" <[EMAIL PROTECTED]> writes: >[EMAIL PROTECTED] (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 [EMAIL PROTECTED]