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

At Mon, 06 Oct 2008 10:51:25 +0200,
Simon Josefsson wrote:
> 
> All,
> 
> 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).
> 
> For more details, including the particular certificate chain in this
> example, see:
> 
> http://thread.gmane.org/gmane.network.gnutls.general/1383/focus=1384
> 
> I can see several reasons to enforce the MUST recommendation here, e.g.,
> covert channels, DoS-considerations, unneeded complexity.

I think there are two separate issues here:

(1) Whether implementations should be required to send certificates
    in a specific order.
(2) Whether implementations should generate an error if they are
    received in another order.

Put me in the "Yes" category for (1). It makes the verifying 
implementation considerably easier. This isn't an issue if
you have a database-based verifier as is required for CMS,
but if you don't, then it's a lot easier to simply verify 
that C_n is verified by C_n+1. So, if you're doing just
a TLS stack and not a generic crypto stack, then this 
restriction helps. PureTLS cares about order.

As for (2), I think that's more debatable. The argument
against it is the usual flexibility argument. The argument
for it is early detection of nonconforming peers. Note that
I don't consider RFC 5246 to require enforcing this MUST.
It's simply silent on this point. Implementations which
verify out of order are still conforming, IMHO.

-Ekr

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls