Strength in Complexity?

[Peter Gutmann]

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.  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".

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.  One of the known problems 
with this is that any cert that's marked as trusted now becomes a root CA cert 
because of the requirement to ignore the fact that it isn't a root CA cert.

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

Peter.

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