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

["Ryan Sleevi" <[e-mail]>]

On Thu, May 7, 2015 1:18 pm, Viktor Dukhovni wrote:
>  That's mostly fine (singular/plural conflict), though one might
>  clarify the MAY further:
>
>    certificate_list
>       This is a list of certificates needed for authentication.
>       The sender's certificate MUST come first in the list.  Additional
>       certificates needed to construct a valid certificate chain
>       SHOULD be ordered by increasing scope of authority.  (e.g.
>       sender, intermediate(s), certificate authority).  Root
>       certificate authority certificates MAY be omitted from the
>       list, provided supported peers are known to possesses any
>       omitted certificates they may require in their trust stores.
>       (When DANE-TA(2) trust-anchors are self-signed roots, they
>       MUST not be omitted [draft-ietf-dane-ops]).

While I appreciate the attentiveness to DANE's needs, it seems unnecessary
to specify profile-specific details in the TLS specification, much in the
same way we don't discuss profile-specific aspects of ciphersuite
negotiations or the like. That is, I consider DANE-TA(2) trust anchors as
a profile of how the TLS exchange works, not an intrinsic property that
belongs in this spec.

Regarding Dave's suggested rewording on the additional certificates, I
think there's actually sizable ambiguity with respect to the terms chosen
(sender, intermediate(s), certificate authority) that the original
language is much clearer and less ambiguous on.

At the risk of a bike-shed, I'll throw my contribution in, which aligns
closer to the existing language, save for avoiding the notion of "root
certificate authority certificates" in favour of the RFC 5280 term of
trust anchor, which need not necessarily be a certificate. Functionally,
this is equivalent, but hopefully provides clearer understanding.

  This is a sequence (chain) of certificates. The sender's certificate
  MUST come first in the list. Each following certificate SHOULD
  directly certify the one preceding it. Because certificate validation
  requires that trust anchors be distributed independently, a
  self-signed certificate that specifies the trust anchor MAY be omitted
  from the chain, provided supported peers are known to possess any
  omitted certificates they may require.

So, for the DANE-TA(2) trust-anchor form, it requires that the trust
anchor be express as a self-signed certificate, and is not possessed by
the peer, ergo the MAY doesn't apply and the peer MUST send the
certificate. But it avoids the cross-reference to a particular trust
validation method.