> On Mar 23, 2017, at 10:31 AM, Fries, Steffen <steffen.fr...@siemens.com>
> wrote:
>
> According to TLS 1.2 section 7.4.1.4.1. a client may use the
> signature_algorithm extension to signal any combinations the
> client supports, listed in the order of preferences.
The signature algorithm is primarily about signatures made as part
of the TLS handshake, and not so much signatures in certificates.
> If the client does not use this extension, the server must use the
> signature algorithm in combination with SHA1.
For signing the TLS key exchange, however, it should still present
whatever certificate chain it has, even if that chain employs SHA256.
It is exceedingly unlikely these days that a client will not support
SHA256 signatures in the certificate chain.
> This may lead to an error on the client side when validating the
> certificate.
You really should not even deploy SHA1 certificates these days, though
some sites are still using their legacy SHA1 certificates that have not
yet expired.
> Unfortunately the server is not allowed to use this extension, otherwise
> he could tell the client his preferences according to his security policy.
The protocol (as it should) lacks the additional round-trips necessary for
the server to initiate signature algorithm negotiation.
> Is there a standard compliant way to utilize SHA256 based certificates on
> the server side even when a client does not signal additional signature
> algorithms?
Yes, just use them regardless of the client's signature algorithm
extension. See the TLS 1.3 draft for improved language about the
interaction of signature algorithms and certificates.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
