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

[[e-mail] (Martin Rex)]

Kemp, David P. wrote:
> There is nothing wrong with the client accepting a bag 'o certs that
> is 1) incomplete, 2) has extra certs, or 3) has the exact number of
> certs in the exact order needed to chain back to a server-trusted
> root, as long as the client can validate a path back to a
> client-trusted root (using either cached or fetched certs if the
> bag doesn't work).

This is the TLS WG mailing list and the TLS protocol.  You might be
confusing this discussion with PKIX and CMS.

None of what you enumerate applies to the TLS Certificate handshake
message, because this carries well-explained MUSTs.


>
> PKIX specifies validation requirements that
> do not require servers to send anything, and sending a full path
> with every handshake is an efficiency gain for the first connection
> but a waste for all the rest.

For PKIX (rfc5280), the building of a certification path has been EXPLICITLY
declared "out of scope", and it is pretty normal for TLS peers to not
contain any kind of path building functionality and not to know more
than "trust anchors" for verification of certificate chains provided
by peers.

What we're looking at here, is **interoperability** requirements.


> 
> Servers can be strict in what they send by sending a server-trusted
> path in chaining order as you suggest.

This is an obvious misunderstanding of the TLS specification and the
requirements keyword MUST:

https://tools.ietf.org/html/rfc2119#section-1

  1. MUST
   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

Sending a complete and ordered certificate chain in the "certificate_list"
element of the TLS Server Certificate handshake message is not an option,
is is an "ABSOLUTE REQUIREMENT".


>
> But clients that cannot construct a valid path on their own if the
> server's doesn't satisfy them are insufficiently liberal.

Clients do not have to accomodate server that violate MUSTS.  In most cases,
it is detrimental and often dangerous to work around such protocol
violations by the peer.

And if all of what the client has is a very short list of trust anchors
(in the optimal and safe configuration just one single trust anchor),
then there is nothing besides a simple reordering and duplicate cert
elimination that a sensible client can do about a misconfigured server
that is using a defective TLS implementation.

Either the certification path presented by the server crosses through
the trust anchor(s) of the client or ends there -- then you get interop,
or it doesn't then you get interop failure.


-Martin