Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis

[Peter Gutmann <[e-mail]>]

Stephen Checkoway <[e-mail]> writes:

>TLS 1.2 specifies
>
>   If the client provided a "signature_algorithms" extension, then all
>   certificates provided by the server MUST be signed by a
>   hash/signature algorithm pair that appears in that extension.

Which is one of the nonsensical requirements in TLS 1.2 that you pretty much
have to ignore in order to get an implementation that works (it's been
discussed on the list before).  Consider how this is supposed to work in
practice: A client connects to Amazon and asks for ECDSA_P521_WITH_SHA384.
Amazon puts the client on hold and goes to Verisign and requests that they
reissue their entire cert hierarchy up to the root using ECDSA-P521 with
SHA384, and then buys a new certificate using the requested algorithm.  They
then wait for Windows Update to propagate the new CA certs out to the client,
and after a few weeks on hold the client connects.

At the time this was discussed, the approach by everyone who contributed was
that the client got whatever the server had available.  In the rare cases
where the server had more than one cert then "signature_algorithms" could be
used to implement a MAY, but it still won't change the fact that beyond the
server cert you get what the CA gives you and nothing else, no matter what the
TLS 1.2 RFC may wish for.

Peter.