Change:
algorithms in this specification are defined solely for use in legacy certificates, and are not valid for CertificateVerify signatures. <ins> The receiver of a CertificateVerify MUST verify the signature field. The verification process takes as input: The content covered by the digital signature The public key received with the previous Certificate message The digital signature received in the signature field of the CertificateVerify message If the verification fails, the connection MUST be terminated with an "illegal_parameter" alert. </ins> Note: When used with non-certificate-based handshakes (e.g., PSK), the client's signature does not cover the server's certificate directly.  When the PSK was established through a NewSessionTicket,

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.