Eric Rescorla wrote: >> >> based on your reply my conclusion is that >> >> - there is no (standard compliant) way for a server to use a >> SHA256 based certificate for server side authentication in cases where the >> client does not provide the signature_algorithm extension > > Not quite. If the client offers TLS 1.1 or below, then you simply don't > know if it > will accept SHA-256 and you should send whatever you have. If the client > offers > TLS 1.2 and no signature_algorithm extension, then you technically are > forbidden > from sending it a SHA-256 certificate. Note that any client which in fact > supports > SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing it, > is noncomformant. It's not clear to me how many such clients in fact exist.
rfc5246 makes it perfectly compliant for a TLSv1.2 client to support sha256-based signature algorithms and be willing to use them, and *NOT* send the TLS signature_algorithm extension. https://tools.ietf.org/html/rfc5246#appendix-E.2 > > - clients should always use the signature algorithm extension to >> ensure the server can apply a certificate with the appropriate crypt >> algorithms Except that the vast majority of servers only has a single certificate, and will have to do "the right thing" in most situations anyway. The definition of the "signature_algorithms" extensions is sufficiently dense to say that you MUST not send it, except when ClientHello.client_version=(3,3), and it is not possible to send it when using a backwards-compatible SSL version 2 CLIENT-HELLO. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
