Re: [TLS] Update spec to match current practices for certificate chain order

[[e-mail] (Martin Rex)]

Dave Garrett wrote:
> https://tools.ietf.org/html/rfc5246#section-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 seems that in practice, nobody cares about that second "MUST".

That isn't quite accurate.

Up to 2013 our SSL implementation has been hard failing TLS handshakes
with TLS peers that are sending garbled or incomplete chains.

In 2013, I added a _simple_ reordering before certficate path validation.
Missing certificates or alien certificates are still going to result
in a fatal handshake failure.
 
The one thing that I fail to understand: why did SSL implementations
add sorting into the recipient side processing of the TLS Certificate
handshake message, but *NOT* at the same time fix their sender-side
processing of that handshake message to *NOT* send bogus certificat_lists
in the first place.  One of the most notorious offenders is OpenSSL.

-Martin