On Thu, Mar 23, 2017 at 9:44 AM, Martin Rex <m...@sap.com> wrote: > Fries, Steffen 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 > > The statement quoted by Eric is an obvious and silly defect in the spec, > which the entire installed base of TLSv1.0 and TLSv1.1 completely ignored > --even Microsoft's implementation of TLSv1.0 and TLSv1.1 properly ignores > it. >
I don't think this statement is entirely accurate about what the requirements are. - TLS 1.0 and 1.1 did not offer any way for the client to tell the server what algorithms it supported. For this reason, if you receive a TLS 1.0 or 1.1 ClientHello, all you can do is send whatever certificate you have. So, TLS 1.0 and 1.1 implementations are not ignoring any requirement by doing so, rather they are following the specification. - TLS 1.2 implementations which receive TLS 1.2 ClientHellos which either do not have signature_algorithms or which have signature_algorithms without SHA-256 are not supposed to send SHA-256 certificates (per the text I quoted above). Again, I realize opinions differ on the wisdom of this text. The extent to which it is an interop problem depends on how many clients would support SHA-256 but for some reason offer 1.2 w/o the required extension. I would be grateful for any data on the frequency of such clients. - As has been noted elsewhere, TLS 1.3 relaxes the requirement to not send certificates which do not match signature_algorithms. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
