Change:
The algorithm field specifies the signature algorithm used (see signature-algorithms for the definition of this field).  The <del> signature is a digital signature using that algorithm that covers the hash output described in authentication-messages namely: </del> <ins> signature is a digital signature using that algorithm.  The content to be signed is the hash output as described in authentication- messages namely: </ins> <del> In TLS 1.3, the digital signature process takes as input: A signing key A context string The actual content to be signed The digital signature is then computed using the signing key over the concatenation of: </del> <ins> The digital signature is then computed over the concatenation of: </ins> A string that consists of octet 32 (0x20) repeated 64 times

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.