Change:
The only thing that might need text (though I'm not certain) is that this doesn't describe what it means to have signaturealgorithmscert and not signaturealgorithms. I assume that it means that a signature isn't possible. However, in previous versions it would be interpreted to mean something else based on default values for signaturealgorithms.

Discussion:
4.2.3. <del> The client uses the "signature_algorithms" extension to indicate to the server which signature algorithms may be used in digital signatures.  Clients which desire the server to authenticate itself via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a "signature_algorithms" extension, then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions). The "extension_data" field of this extension in a ClientHello contains a SignatureSchemeList value: </del> <ins> TLS 1.3 provides two extensions for indicating which signature algorithms may be used in digital signatures.  The "signature_algorithms_cert" extension applies to signatures in certificates and the "signature_algorithms" extension, which originally appeared in TLS 1.2, applies to signatures in CertificateVerify messages.  The keys found in certificates MUST also be of appropriate type for the signature algorithms they are used with.  This is a particular issue for RSA keys and PSS signatures, as described below.  If no "signature_algorithms_cert" extension is present, then the "signature_algorithms" extension also applies to signatures appearing in certificates.  Clients which desire the server to authenticate itself via a certificate MUST send "signature_algorithms".  If a server is authenticating via a certificate and the client has not sent a "signature_algorithms" extension, then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions). The "signature_algorithms_cert" extension was added to allow implementatations which supported different sets of algorithms for certificates and in TLS itself to clearly signal their capabilities. TLS 1.2 implementations SHOULD also process this extension. The "extension_data" field of these extension contains a SignatureSchemeList value: </ins> %%% Signature Algorithm Extension

with the corresponding hash algorithm as defined in SHS.  These values refer solely to signatures which appear in certificates (see server-certificate-selection) and are not defined for use in <del> signed TLS handshake messages. </del> <ins> signed TLS handshake messages, although they MAY appear in "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2, </ins> Indicates a signature algorithm using ECDSA ECDSA, the corresponding curve as defined in ANSI X9.62 X962 and FIPS 186-4

Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask generation function 1.  The digest used in the mask generation function and the digest being signed are both the corresponding <del> hash algorithm as defined in SHS.  When used in signed TLS handshake messages, the length of the salt MUST be equal to the length of the digest output.  This codepoint is new in this document and is also defined for use with TLS 1.2. </del> <ins> hash algorithm as defined in SHS.  The length of the salt MUST be equal to the length of the digest algorithm.  If the public key is carried in an X.509 certificate, it MUST use the rsaEncryption OID RFC5280. </ins> Indicates a signature algorithm using EdDSA as defined in RFC8032 or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. <ins> Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask generation function 1.  The digest used in the mask generation function and the digest being signed are both the corresponding hash algorithm as defined in SHS.  The length of the salt MUST be equal to the length of the digest algorithm.  If the public key is carried in an X.509 certificate, it MUST use the RSASSA-PSS OID RFC5756.  When used in certificate signatures, the algorithm parameters MUST be DER encoded.  If the corresponding public key's parameters present, then the parameters in the signature MUST be identical to those in the public key. </ins> Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used in this context with either with RSA using RSASSA-PKCS1-v1_5 or ECDSA.  These values refer solely to signatures which appear in certificates (see server-certificate-selection) and are not <del> defined for use in signed TLS handshake messages.  Endpoints SHOULD NOT negotiate these algorithms but are permitted to do so solely for backward compatibility.  Clients offering these values MUST list them as the lowest priority (listed after all other algorithms in SignatureSchemeList).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection). </del> <ins> defined for use in signed TLS handshake messages, even if they appear in the "signature_algorithms" list (this is necessary for backward compatibility with TLS 1.2).  Endpoints SHOULD NOT negotiate these algorithms but are permitted to do so solely for backward compatibility.  Clients offering these values MUST list them as the lowest priority (listed after all other algorithms in SignatureSchemeList).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection). </ins> The signatures on certificates that are self-signed or certificates that are trust anchors are not validated since they begin a

cipher suites.  (see cipher-suites) A TLS-compliant application MUST support digital signatures with <del> rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for </del> <ins> rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256_ (for </ins> CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 RFC7748.

IANA [SHALL update/has updated] this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes", "early_data", "cookie", "supported_versions", <del> "certificate_authorities", "oid_filters", and "post_handshake_auth" extensions with the values defined in this document and the Recommended value of "Yes". </del> <ins> "certificate_authorities", "oid_filters", "post_handshake_auth", and "signature_algorithms_certs", extensions with the values defined in this document and the Recommended value of "Yes". </ins> IANA [SHALL update/has updated] this registry to include a "TLS 1.3" column which lists the messages in which the extension may