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

[Yoav Nir <[e-mail]>]

Hi, Dave

> On May 7, 2015, at 6:13 AM, Dave Garrett <[e-mail]> 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”.

It’s not that nobody cares about that second MUST. It’s just that we’ve learned the hard way that a lot of servers get it wrong, so we anyway had to run the whole chain-sorting/chain-completing code anyway.

> https://bugzilla.mozilla.org/show_bug.cgi?id=619445#c1
> 
> I'd like to propose simply changing that second "MUST" to a "SHOULD" or possibly even a "RECOMMENDED", thus allowing for clients to accept cert chains in different orderings as they already seem to do. (no change proposed for the first "MUST”)

People get it wrong, so let’s make it easy for them by relaxing the requirement?  Bleh. Might save some people from learning the hard way that others get it wrong.  But the thing with SHOULDs is that we usually want an explanation of when it is OK to not follow the SHOULD. I can’t think of any text for that.

> I think there was also discussion on this list at some point suggesting changing that "MAY" for omitting the root CA cert to a "SHOULD" or a "MUST". (I think the argument for the latter was to reduce wasted bandwidth)

SHOULD is OK, MUST would imply perfect knowledge of how the other side is configured. The root of trust may or may not be the self-signed certificate. But it’s probably always fine to omit the self-signed certificate.

> Any reason this would be problematic? It'd be a simple change to add for the TLS 1.3 spec that would align things better with real-world usage.

None that I can think of

Yoav