Re: [TLS] Signature Algorithms

[Viktor Dukhovni <[e-mail]>]

On Tue, Mar 17, 2015 at 06:10:25PM +0000, Mehner, Carl wrote:

> If we want to drop MD5 EE-certs by removing MD5 from the signature
> algorithms, and you want to keep your long term SHA-1 EE-cert that has a
> chain which is capped by an MD5 root, you would not be able to send that
> root in the certificate_list as the document is written today. The text
> I suggested allows you to still send the root.

It may be sensible to recognize that in many cases the server has
a single certificate chain and can only send that regardles of what
the client's signature algorithms extension indicates.

Therefore, though when possible, the server should prefer to send
something that the client is known to support, the server should
be able to send whatever it has, and it is then up to the client
to accept that, or not.

At that point, the client may choose to only validate the signatures
that matter.  In particular self-signatures might not be validated,
and their algorithm might be ignored.  Similarly the signature of
a DANE-TA(2) issuer CA (self-signed or not) would typically be
ignored, because the trust-anchor vouching for that is DNSKEY of
the zone with the TLSA RRset, and not the signer of the CA certificate.

>    If the client provided a "signature_algorithms" extension, then all
>    certificates provided by the server, except for the self-signed root
>    CA certificate, MUST be signed by a hash/signature algorithm pair that
>    appears in that extension.

Therefore, even this is likely wrong.  The server SHOULD try to
send conformant chains, but is under no obligation to perform magic,
and should not unilaterally abort the connection when it can't.

This is what happens in practice anyway, servers send what they
have, ignoring this requirement.  The real question is what should
clients do.

-- 
	Viktor.