Draft: draft-ietf-tls-tls13

Commentary: Current client implementations allow more flexible certificate ordering than the spec allows and some server implementations send certificates in orders that the spec says " MUST " not be done . Relaxing the language here to a " SHOULD " is appropriate so implementers following this spec know that such situations need to be handled . Enforcing this more strictly would cause interop problems for no practical gain . The modified language here is based on the mailing list discussion . 
 This seems like a really bad idea , since it will reduce interoperability even further . 
 If you 'd like to explain how formally documenting existing behavior ( that we are not otherwise proposing be changed ) will somehow reduce interoperability further , then please do so on the mailing list . This proposal is only to properly document existing capabilities such that all readers of the spec actually know what to expect here . Not doing this requires either intentionally having a part of the spec we know to be wrong in practice , or changing this to require more strict error enforcement that would break interop . 
   posted to the list an in - depth argument as to why the prior requirement can be considered harmful . I 'll cite it here for reference , as the threads on this topic got long and winding : 
 Rebased . Last discussion of this on - list ended with lots of agreement and one strong dissenter . Are you able to declare a rough consensus to merge this , or is more discussion needed ? Note that this is already in " running code " , as this merely documents existing practice in some implementations . 
 can this be merged ? 
 Ok , revised and rebased . Please take a look . 
 Rebased . FTR in this PR , question from answered on - list : ( GitHub 's logic is that if you comment on a commit directly , as apposed to the changeset in the PR , then rebasing ditches your comment from the PR ; old comments on the PR get collapsed above , but are still here ) I do n't know the WG policy here . Is approval sufficient sign - off for you to merge , or do we need  from the list : On We d , Aug 26 , 2015 at 02:11:01PM -0700 ,   wrote : [ question asked and satisfactorily answered by   ; link above ] On We d , Aug 26 , 2015 at 10:25:07PM -0700 ,   wrote : So , is this finally ready to land now ?
Paragraph (version B):
Relax certificate_list ordering requirement to match current
practice.
Paragraph (version A):
This is a sequence (chain) of certificates.  The server's
certificate MUST come first in the list.  Each following
certificate MUST directly certify the one preceding it.  Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certification authority (CA) MAY be omitted from the chain, under
the assumption that the client must already possess it in order to
validate it in any case.
Paragraph (version B):
This is a sequence (chain) of certificates.  The sender's
certificate MUST come first in the list.  Each following
certificate SHOULD directly certify one preceding it.  Because
certificate validation requires that trust anchors be distributed
independently, a self-signed certificate that specifies a trust
anchor MAY be omitted from the chain, provided that supported
peers are known to possess any omitted certificates they may
require.
Paragraph (version B):
Note: Prior to TLS 1.3, "certificate_list" ordering was required to
be strict, however some implementations already allowed for some
flexibility.  For maximum compatibility, all implementations SHOULD
be prepared to handle potentially extraneous certificates and
arbitrary orderings from any TLS version (with the exception of the
sender's certificate).  Some servers are configured to send both a
current and deprecated intermediate for transitional purposes, and
others are simply configured incorrectly, but these cases can
nonetheless be validated properly by clients capable of doing so.
Whilst the chain MAY be ordered in a variety of ways, the peer's end-
entity certificate MUST be the first element in the vector, and
implementations MUST abort with a fatal "bad_certificate" alert in
the event that this is not the case.