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

[[e-mail] (Martin Rex)]

Dave Garrett wrote:
> A PR with language based on this discussion:
> https://github.com/tlswg/tls13-spec/pull/169/files
> 
> The text is mostly the same or similar, with the second "MUST" changed
> to a "SHOULD", and the term "trust anchor" replacing references to root
> keys/CA.
> 
> Is this changeset acceptable?


I am violently opposed to this change.

It creates new ambiguities, makes bogus, backwards-incompatible
and interoperability-impairing behaviour appear less objectionable,
while providing _zero_ benefit.


The "original" requirements apply to the server's Certificate
handshake message, i.e. which certificates and in what order the
server is required to encode into the Server Certificate handshake
message.

The purpose of these requirements for the server is to facilitate
the the client's job to verify the server's certificate, improve
interoperability and create a predictable&deterministic client
behaviour that should be independent from the particular client
implementation as much as possible.

Clients that are willing to perform unsafe path discovery on
a Server's certificate handshake message will *NOT* be inconvenienced
if the server puts the certificates in correct order and optionally
omits only the self-signed rootCA certificate at the end.

Clients that do not perform any fancy unsafe path discovery, on the
other hand, may easily be non-interoperable with sloppy servers that
do not properly compose their Server Certificate handshake message,
and these Client are _not_ to blame for any resulting interop failure,
because it is clearly the server TLS implementation that goofed
when it produces a Server Certificate PDU that violates the MUSTs.


-Martin