Draft: draft-ietf-tls-tls13

Commentary: The client should be required to verify the CertificateVerify message . In addition I prefer to specify the alert type in case the verification fails ( also for the Finished ) . 
 can you please rebase this ? 
 I tried my best to rebase the PR . Not sure though I did it the right way . can you provide feedback ? 
 I do n't think it looks like the desired rebase . IIRC you have to use command - line git to do this rebase , and the workflow is something like : which assumes that origin is and the ' github ' remote is your personal github fork ; modify accordingly . I am not sure if there will be any rebase conflicts that need to be resolved ( there may not be , since you just have merge commits for changes you want to rebase past ) , but if not , there should be some documentation online for generic git conflict resolution scenarios . 
 Ok , so some homework for me to do . :) 
 Hopefully the PR now looks better . Sorry for my missing git experience . :) 
 Yes , the commit structure is as desired , now . ( No comment on the actual contents , yet , though ;) ) 
 Probably worth saying , but I agree with MT that there 's room for more detail about what exactly is verified , how it relates to the immediately prior Certificate message , how the x509 certificates therein are bound to any SNI in the handshake , etc . 
 btw , pointed to me that was more ambiguous about this : I find that weird , but I 'm happy that TLS 1.3 would change that to a MUST . 
 Some things need to be sorted out first . IMO there are several validations regarding the certficate : validation of the identity provided in the certificate . On the client side his can be a consistency check against the SNI , if provided by the application , but it can be something else as well ( e.g. externally received fingerprint of the certificate ) . I believe it depends too much on the use case to turn this validation into a MUST . validation of the certificate 's structure . This is out of scope of TLS , see section 4.4.1.4 . verification that the sender possesses the private key . Here I agree this should be a MUST , and that is addressed by this PR . 
 The text in the PR could be a little more clear that that is what is being validated . 
 I just updated the PR and provided more details for the verification process ( which required some restructuring of the CertificateVerify section ) . 
 please provide a PR to add yourself to the contributors list . 
 A separate PR has been created ( ) to extend the distribution list .
Paragraph (version A):
If sent by a server, the signature algorithm MUST be one offered in
the client's "signature_algorithms" extension unless no valid
certificate chain can be produced without unsupported algorithms (see
signature-algorithms).
Paragraph (version B):
If the CertificateVerify message is sent by a server, the signature
algorithm MUST be one offered in the client's "signature_algorithms"
extension unless no valid certificate chain can be produced without
unsupported algorithms (see signature-algorithms).
Paragraph (version B):
If the verification fails, the connection MUST be terminated with an
"illegal_parameter" alert.
Paragraph (version A):
Recipients of Finished messages MUST verify that the contents are
correct.  Once a side has sent its Finished message and received and
validated the Finished message from its peer, it may begin to send
and receive application data over the connection.  Early data may be
sent prior to the receipt of the peer's Finished message, per early-
data-indication.
Paragraph (version B):
Recipients of Finished messages MUST verify that the contents are
correct.  If the verification fails, the connection MUST be
terminated with an "illegal_parameter" alert.
Paragraph (version B):
Once a side has sent its Finished message and received and validated
the Finished message from its peer, it may begin to send and receive
application data over the connection.  Early data may be sent prior
to the receipt of the peer's Finished message, per early-data-
indication.