On Mon, Jul 13, 2015 at 04:11:04AM +0000, Andrei Popov wrote:
> I'm not happy with this either. The spec already says:
>
> "If the client supports only the default hash and signature algorithms
> (listed in this section), it MAY omit the signature_algorithms
> extension. If the client does not support the default algorithms, or
> supports other hash and signature algorithms (and it is willing to
> use them for verifying messages sent by the server, i.e., server
> certificates and server key exchange), it MUST send the
> signature_algorithms extension, listing the algorithms it is willing
> to accept."
>
> This seems to be pretty clear: if the client properly advertises the
> algorithms it supports, then the handshake has a deterministic outcome.
That's all fine, we're talking about what the server should do when
it is certificate chain does not (in its entirety) match those
algorithms. And in the context of TLS 1.3 which is not yet set in
stone.
Which part are you objecting to? The subsequent proposal to suppress
SHA-1 advertisements (if the client supports only TLS 1.3 or later)
when even when the client is willing to accept a SHA-1 chain when
all else fails? That too seems sensible, and it was already noted
that clients will need to send the SHA-1 codepoint when willing to
accept TLS 1.2, since that spec does not contain the proposed new
language for server-side behaviour.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
