Original text:
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>  <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>  A string that consists of octet 32 (0x20) repeated 64 times 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>  <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>  If sent by a client, the signature algorithm used in the signature MUST be one of those present in the supported_signature_algorithms algorithms in this specification are defined solely for use in legacy certificates, and are not valid for CertificateVerify signatures.  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, and of the computed keys. Recipients of Finished messages MUST verify that the contents are <del> 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. </del>  The key used to compute the finished message is computed from the Base key defined in authentication-messages using HKDF (see key-

Reviewer comments:
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.

Revised text:
The algorithm field specifies the signature algorithm used (see signature-algorithms for the definition of this field).  The  <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>  <ins> The digital signature is then computed over the concatenation of: </ins> A string that consists of octet 32 (0x20) repeated 64 times CertificateVerify". For example, if Hash(Handshake Context + Certificate) was 32 bytes of  <ins> 01 (this length would make sense for SHA-256), the content covered by the digital signature for a server CertificateVerify would be: </ins>  <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 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, and of the computed keys. Recipients of Finished messages MUST verify that the contents are  <ins> correct.  If the verification fails, the connection MUST be terminated with an "illegal_parameter" alert. 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. </ins> The key used to compute the finished message is computed from the Base key defined in authentication-messages using HKDF (see key-