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

[Viktor Dukhovni <[e-mail]>]

On Sat, May 09, 2015 at 12:49:16AM -0400, Dave Garrett wrote:

> > It creates new ambiguities, makes bogus, backwards-incompatible
> > and interoperability-impairing behaviour appear less objectionable,
> 
> Yep, but it does convert interoperability-impairing behavior into interoperable behavior.

On the contrary, the currently required server behaviour is
interoperable, and relaxing the rules is likely to reduce that
interoperability if more servers violate the rules.

The fact that many clients don't enforce the rules is not surprising,
there is no Internet protocol police, and the spec does not require
clients to enforce the rules.

We must read the spec exclusively as a server requirement to order
the chain.  Client obligations in particular TLS applications may
vary from application to application.  Browsers may well jump
through various hoops, and likely need to do so.  Other applications
do not.  The world-wide-web is not the entire Internet, and browsers
are not the only TLS-using applications.

For example, Postfix (when configured to validate peer certificates
via a set of local trust-anchors) does not tolerate missing
intermediate certificates, the trust store it uses for this typically
contains only self-signed trust-anchor certs.

Yes, I know that the specific change of language is only about
certificate order, and does not remove the requirement to send all
the requisite certs.  And in fact Postfix does tolerate out-of-order
intermediates (because OpenSSL does).  So my example is but an
analogy, and does not *specifically* warrant retaining the order
constraint, but other clients may be even more constrained, and
that's OK for those particular applications.

Nothing in the current server requirement precludes any client
accomodations for servers that don't send the requisite chain.
When those are appropriate, they can be employed.

-- 
	Viktor.