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. The only defective TLS implementation, that I am aware of, which put this silly and obviously backwards-incompatible and defective requirement from rfc5246 into code, seems to be Microsofts TLSv1.2 implementation in Windows 7 through Windows 8.1. One can interop with Windows 7 through Windows 8.1 just fine without signature_algorithms when offering at most TLSv1.1, or offering TLSv1.2 in a SSL version 2 CLIENT-HELLO (in which case Microsoft SChannel will negotiate TLSv1.1). > > - clients should always use the signature algorithm extension to ensure > the server can apply a certificate with the appropriate crypt algorithms Unless the server is creating his own certificate on the fly, the signature algorithm on the server certificate is something which the server has no control over, and which is therefore quite obviously not up for negotiation in the TLS protocol handshake. signature_algorithms can only be normative for signatures created as part of the TLS handshake. For signature algorithms on certificates, it is a simple selection hint (similar to TLS extension server_name_indication only being a selection hint). That is a thoroughly intuitive requirement for backwards compatibility. Btw. there are a number of defects in the TLS spec (and the TLSv1.2 spec rfc5246 in particular), one is introducing (rsa,md5) as a permissible signature algorithm into TLSv1.2 handshakes. While obvious to anyone with a clue, it took a few implementors several years to understand that blindly following wording of a "proposed standard" specification is a terribly bad idea and a poor excuse for lack of common sense and lack of interop testing. For those who missed the defect on reading, a simple interop test will make this specification defect stand out like a sore thumb. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
