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

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.

What are others opinion on this?  I'm looking for some guidance on
whether we should modify our current behaviour.

/Simon

Peter Volkov <pva@gentoo.org> writes:

> Is it possible to do something similar in gnutls? It looks like there
> are reasons to validate certificate with wrong order...
>
> -------- Forwarded message --------
> From: Tim Hudson <tjh AT cryptsoft  com>
> Reply-TO: openssl-dev@openssl.org
> TO: openssl-dev@openssl.org
>
> Peter Volkov wrote:
>> CC'ing openssl developers for their opinions, since I think this
>> behavior better to have consistent or configurable. Description of the
>> problem is here:
>
> Placing this in context - connect with internet explorer or firefox to 
> https://metasploit.com/ and you will see that both of those independent 
> implementations see nothing wrong with the certificate chain and handle the 
> redirect to http://metasploit.com/ without and errors or warnings.
>
> Implementations typically take the list of certificates as untrusted 
> certificates to add into the process of walking the certificate chain to a 
> trusted root certificate. There are pragmatic reasons for doing it this way.
>
>  From an interoperability point of view remember the adage - "Be strict in what 
> you generate, be liberal in what you accept"
>
> Tim.
> ______________________________________________________________________
>
>
> -- 
> Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls