Draft: draft-ietf-tls-tls13

Commentary: In your answer to my question on list you say : and chain validation . I do n't see that covered by this PR . Should n't this be explicit ? 
 then the " signature_algorithms " extension also applies to signatures appearing in certificates . is unaffected by this change 
 As says , there is already text that implies that you need not send " signature_algorithms " cert , so I do n't think new text is really needed here . 
 That sentence says nothing about under what circumstances it is ok to omit " signaturealgorithms_cert " . It only implies that you may not always get it . I think it would not hurt to be more explicit .
Paragraph (version A):
The "signature_algorithms_cert" extension was added to allow
implementations 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 B):
The "signature_algorithms_cert" extension was added to allow
implementations 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.
Implementations which have the same policy in both cases MAY omit the
"signature_algorithms_cert" extension.
Paragraph (version A):
In prior versions of TLS, the CertificateRequest message carried a
list of signature algorithms and certificate authorities which the
server would accept.  In TLS 1.3 the former is expressed by sending
the "signature_algorithms" extension.  The latter is expressed by
sending the "certificate_authorities" extension (see certificate-
authorities).
Paragraph (version B):
In prior versions of TLS, the CertificateRequest message carried a
list of signature algorithms and certificate authorities which the
server would accept.  In TLS 1.3 the former is expressed by sending
the "signature_algorithms" and "signature_algorithms_cert"
extensions.  The latter is expressed by sending the
"certificate_authorities" extension (see certificate-authorities).
Paragraph (version A):
The certificate MUST allow the key to be used for signing (i.e.,
the digitalSignature bit MUST be set if the Key Usage extension is
present) with a signature scheme indicated in the client's
"signature_algorithms" extension.
Paragraph (version B):
The certificate MUST allow the key to be used for signing (i.e.,
the digitalSignature bit MUST be set if the Key Usage extension is
present) with a signature scheme indicated in the client's
"signature_algorithms"/"signature_algorithms_cert" extensions (see
signature-algorithms).
Paragraph (version A):
All certificates provided by the server MUST be signed by a signature
algorithm that appears in the "signature_algorithms" extension
provided by the client, if they are able to provide such a chain (see
signature-algorithms).  Certificates that are self-signed or
certificates that are expected to be trust anchors are not validated
as part of the chain and therefore MAY be signed with any algorithm.
Paragraph (version A):
If the server cannot produce a certificate chain that is signed only
via the indicated supported algorithms, then it SHOULD continue the
handshake by sending the client a certificate chain of its choice
that may include algorithms that are not known to be supported by the
client.  This fallback chain SHOULD NOT use the deprecated SHA-1 hash
algorithm in general, but MAY do so if the "signature_algorithms"
extension provided by the client permits it, and MUST NOT do so
otherwise.
Paragraph (version B):
All certificates provided by the server MUST be signed by a signature
algorithm advertised by the client, if they are able to provide such
a chain (see signature-algorithms).  Certificates that are self-
signed or certificates that are expected to be trust anchors are not
validated as part of the chain and therefore MAY be signed with any
algorithm.
Paragraph (version B):
If the server cannot produce a certificate chain that is signed only
via the indicated supported algorithms, then it SHOULD continue the
handshake by sending the client a certificate chain of its choice
that may include algorithms that are not known to be supported by the
client.  This fallback chain SHOULD NOT use the deprecated SHA-1 hash
algorithm in general, but MAY do so if the client's advertisement
permits it, and MUST NOT do so otherwise.