At 12:48 AM +1200 7/6/08, Peter Gutmann wrote:
Florian Weimer <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
