Strength in Complexity?

[Paul Hoffman]

At 12:48 AM +1200 7/6/08, Peter Gutmann wrote:
>Florian Weimer <fw at deneb.enyo.de> writes:
>>* Peter Gutmann:
>>>  [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?
>>
>>Are you sure that the constraints are not supposed to be applied when
>>the root certificate is actually processed, after its signature has been
>>verified by the trust anchor?
>
>Yup.  The app is supposed to read the cert, parse and process the extensions,
>and then throw them away.

Peter: please turn down the hyperbole a bit. You forgot the word 
"may" between "and" and "then".

>The text from the spec is:
>
>   3.3.60 trust anchor: A trust anchor is a set of the following information in
>   addition to the public key: algorithm identifier, public key parameters (if
>   applicable), distinguished name of the holder of the associated private key
>   (i.e., the subject CA) and optionally a validity period. The trust anchor
>   may be provided in the form of a self-signed certificate. A trust anchor is
>   trusted by a certificate using system and used for validating certificates
>   in certification paths.
>
>Rendered into English, that says "take the pubic key, owner name, and
>validity period, and ignore everything else in the cert".

Wrong. There is no requirement to "ignore everything else in the 
cert". There is simply no requirement to use that material.

>To pre-empt the inevitable "yes, but it doesn't explicitly say you can't
>process the extensions if you want to": It also doesn't say you can't reformat
>the user's hard drive when you see a cert, but the intent is that you don't do
>anything not explicitly listed in the text above.

No offense, but if I wanted to know the intent of a group of people 
who make hard-to-read-and-harder-to-impelemnt crypto standards, I 
would not ask you. You don't know their intent, Peter: you only know 
the output of the sausage-making process.

If I haven't made it clear: I agree with Peter that the spec should 
have clearly stated what one was supposed to do with the extensions. 
Where I think we disagree is that I would rather that the spec said 
explicitly to throw them away. I would rather have the semantics of 
"this is what I say my name is and this is what I say my public key 
is" quite separate from "this is what I think you should trust me to 
authenticate". This adds complexity (it takes two certs), but it also 
reduces complexity (it doesn't mandate binding policy to 
identification).

>Luckily no sane implementation pays any attention to this nonsense :-).

We might agree here because I don't think there are many sane 
implementations of X.509.

--Paul Hoffman, Director
--VPN Consortium

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