Strength in Complexity?

Florian Weimer fw at deneb.enyo.de
Sat Jul 5 09:03:37 EDT 2008


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

Let me rephrase my remark: The trust anchor is conceptually separate
from a root CA certificate.  It is only used to validate it the CA
certificate.  Nothing in that section gives you permission to ignore
extensions on the CA certificate (skipping the first entry in the
certification path).  In addition, the trust anchor cannot be used
directly to verify certificates issued by the CA because the subject DN
does not match.  Ergo, the extensions on the CA certificate are still in
force.

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

I think your interpretation actually leads to a non-compliant
implementation.  Obviously, wording of that section could be less
confusing.

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



More information about the cryptography mailing list