Change:
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

Discussion:
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.