On Thu, Mar 23, 2017 at 10:24 AM, Martin Rex <m...@sap.com> wrote: > 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
Yes, I agree with this, if you use the v2 ClIENT-HELLO. -Ekr > - 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
