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

[Geoffrey Keating <[e-mail]>]

Yoav Nir <[e-mail]> writes:

> 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”)

I'd like to see wording as follows:

     This is a sequence of certificates.  The sender's certificate
     MUST come first in the list.  The remaining certificates MAY be
     used by the client to establish trust in the first certificate.
     The sender SHOULD order these remaining certificates so that each
     certificate is used to establish trust in a certificate earlier
     in the order, and so that its preferred certificates are listed
     first.

This answers the problem of multiple certificate paths, and doesn't
prevent re-ordering by the client, and also allows the server to guide
the client to the chain it prefers, which is important in some
circumstances.  For example, one chain might support EV, and another
might be necessary for older clients, but both might be valid in some
clients; the server would want to guide the client to the EV chain if
it will work.

Another alternative would be to say

     This is a sequence of certificates.  The sender's certificates
     MUST come first in the list.  The remaining certificates MAY be
     used by the client to establish trust in one of the sender's
     certificates.  The sender SHOULD order these remaining
     certificates so that each certificate is used to establish trust
     in a certificate earlier in the order, and so that its preferred
     certificates are listed first.

This explicitly allows the sender to send multiple certificates for
itself, which would simplify a bunch of problems; SNI is no longer
necessary (but still desirable), and it's no longer necessary to
negotiate the certificate signing algorithms.