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

[Ben Laurie <[e-mail]>]

On 7 May 2015 at 04:13, 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".
>
> 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")

No thanks. Let's not encourage bad practices. For a start, if you
relax the requirement you allow for ambiguous chains.

> 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)
>
> 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.
>
>
> Dave
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls