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

[Dave Garrett <[e-mail]>]

On Thursday, May 07, 2015 01:49:21 am Yoav Nir wrote:
> > On May 7, 2015, at 6:13 AM, Dave Garrett <[e-mail]> wrote:
> > 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.

By "nobody cares" I mean that clients seem to be fine handling this now, even if they'd rather not have had to. I don't see vendors evangelizing the proper ordering of certs as a high priority.

> People get it wrong, so let’s make it easy for them by relaxing the requirement?  Bleh. Might save some people from learning the hard way that others get it wrong.

Well, we don't get anything from telling people to panic and abort the connection if it's wrong. Handling the possibility of out-of-order certs is already a thing that has to be done in practice, so stating that up front would improve real-world interop for any clients that might've done otherwise.

In any case, there's not much point in having a "MUST" in the spec that doesn't really help and won't be enforced.

>  But the thing with SHOULDs is that we usually want an explanation of when it is OK to not follow the SHOULD. I can’t think of any text for that.

With Mozilla's phase out of 1024-bit roots, some sites followed recommendations to have two intermediates as a transitional measure. This may be useful for future transitions as well. (not clear on the details here; please correct me if I'm wrong)

> > 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)
> 
> SHOULD is OK, MUST would imply perfect knowledge of how the other side is configured. The root of trust may or may not be the self-signed certificate. But it’s probably always fine to omit the self-signed certificate.
> 
> > 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.
> 
> None that I can think of
> 
> Yoav

On Thursday, May 07, 2015 01:50:18 am Peter Gutmann wrote:
> I suspect the first MUST can go as well, particularly if you're using code
> that handles cert chains in other formats like CMS/PKCS #7, where the "chain"
> can contain any old rubbish and the chain-assembly code has to build the path.
> For example my code looks for a cert containing the site name 
> ("www.whatever.com") and then builds a chain up via the parent links until it
> can't find any more useful certs.  That just works no matter what the other
> side sends.
> 
> Peter.

We might just want to SHOULD-ify the whole thing, then.

Here's a stab at a rewrite with SHOULDs and generalized language:
----------------------------------------------------------------------
  certificate_list
     This is a list of certificates needed for authentication.
     The sender's certificate SHOULD come first in the list, followed
     by additional certificates ordered by increasing authority.
     (e.g. sender, intermediate(s), certificate authority)
     Root certificate authority certificates SHOULD NOT be provided
     in this list, as validation generally requires the root keys be
     distributed independently.
----------------------------------------------------------------------

That may need some tweaking, but I think it clearly outlines the expectations and reasoning.

How does that sound?


Dave