Change:
CertificateVerify". For example, if Hash(Handshake Context + Certificate) was 32 bytes of <del> 01 (this length would make sense for SHA-256), the input to the final signing process for a server CertificateVerify would be: </del> <ins> 01 (this length would make sense for SHA-256), the content covered by the digital signature for a server CertificateVerify would be: </ins> <del> 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). </del> <ins> On the sender side the process for computing the signature field of the CertificateVerify message takes as input: The content covered by the digital signature The private signing key corresponding to the certificate sent in the previous message 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). </ins> If sent by a client, the signature algorithm used in the signature MUST be one of those present in the supported_signature_algorithms

Discussion:
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).
NAME can you please rebase this?
I tried my best to rebase the PR. Not sure though I did it the right way. NAME can you provide feedback?
I don'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 URL 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, NAME 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).
NAME please provide a PR to add yourself to the contributors list.
A separate PR has been created (URL) to extend the distribution list.