Draft: draft-ietf-tls-tls13

Commentary: The only thing that might need text ( though I 'm not certain ) is that this does n't describe what it means to have signaturealgorithmscert and not signaturealgorithms . I assume that it means that a signature is n't possible . However , in previous versions it would be interpreted to mean something else based on default values for signaturealgorithms .
Paragraph (version A):
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).
Paragraph (version B):
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).
Paragraph (version B):
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.
Paragraph (version A):
Indicates a signature algorithm using RSASSA-PKCS1-v1_5 RFC8017
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
signed TLS handshake messages.
Paragraph (version B):
Indicates a signature algorithm using RSASSA-PKCS1-v1_5 RFC8017
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
signed TLS handshake messages, although they MAY appear in
"signature_algorithms" and "signature_algorithms_cert" for
backward compatibility with TLS 1.2,
Paragraph (version A):
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.  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.
Paragraph (version A):
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
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).
Paragraph (version B):
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 rsaEncryption OID
RFC5280.
Paragraph (version B):
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.
Paragraph (version B):
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
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).
Paragraph (version A):
A TLS-compliant application MUST support digital signatures with
rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
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.
Paragraph (version B):
A TLS-compliant application MUST support digital signatures with
rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256_ (for
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.
Paragraph (version A):
IANA [SHALL update/has updated] this registry to include the
"key_share", "pre_shared_key", "psk_key_exchange_modes",
"early_data", "cookie", "supported_versions",
"certificate_authorities", "oid_filters", and
"post_handshake_auth" extensions with the values defined in this
document and the Recommended value of "Yes".
Paragraph (version B):
IANA [SHALL update/has updated] this registry to include the
"key_share", "pre_shared_key", "psk_key_exchange_modes",
"early_data", "cookie", "supported_versions",
"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".