Re: [TLS] Verifying X.509 Certificate Chains out of order
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] Verifying X.509 Certificate Chains out of order



Simon Josefsson wrote, On 2008-10-06 01:51:

> We've received a request to verify X.509 certificate chains out of order
> in GnuTLS.  Doing that would violate the following in RFC 5246 (earlier
> versions had similar language), §7.4.2:
> 
>    certificate_list
>       This is a sequence (chain) of certificates.  The sender's
>       certificate MUST come first in the list.  Each following
>       certificate MUST directly certify the one preceding it.  Because
>       certificate validation requires that root keys be distributed
>       independently, the self-signed certificate that specifies the root
>       certificate authority MAY be omitted from the chain, under the
>       assumption that the remote end must already possess it in order to
>       validate it in any case.
> 
> It is claimed that OpenSSL, IE and Firefox does not enforce the second
> MUST in the paragraph above, and succeeds in verifying an
> out-of-sequence chain.  I haven't verified the claim.  It appears as if
> the OpenSSL developers don't consider their behaviour as a bug (see
> reply below).

I confirm the claim for Firefox and any other NSS-based applications.

NSS holds on to the first cert presented, and throws the rest into a
bucket, into which it has also thrown all locally trusted (i.e., root)
CA certs, and into which the application may have placed CA certs from
other cert chains that were successfully validated in the recent past.
Then beginning with the first cert that it received from the TLS peer,
NSS attempts to reconstruct a cert chain from the certs in that bucket,
one that leads to a locally trusted CA cert, and if it succeeds, it tests
the validity of that chain.  (This description is somewhat oversimplified.)
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.