Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

[Viktor Dukhovni <[e-mail]>]

On Wed, Jul 08, 2015 at 10:25:31PM +0300, Yoav Nir wrote:

> If instead we lived in a world where client certificates were provided
> from commercial CAs, we would have trouble - perhaps the same CA issued
> both the bank certificates and the SSL VPN certificate. How would the
> browser know to send the correct identity? I don?t know the answer to this
> hypothetical question about a hypothetical problem in a hypothetical
> situation, but I?m pretty sure the answer is not to hope that the CA issues
> certificates with different algorithms.

Which I think supports my view, that signature algorithm constraints
ought not strictly apply to client certificates.

However, in the DANE WG we're going to be discussing an extension
of DANE TLSA to client authentication, where "client" will typically
not mean "user with a browser", but  rather will likely be another
server that initiates a connection.  Such "clients" are just as
likely to have multiple chains (varying by algorithm) as the servers
they connect to (that is unlikely in both cases, but not never).

Such clients are very likely to completely ignore the server's CA
hints, and use whatever cert chain they have (modulo signature
algorithm selection).

So the question still stands, is sending what you have prohibited,
or is the supported algorithms extension (in the context of
certificate signatures) a hint to maximize interoperability, and
not a prohibition of the algorithms not listed.

I rather think that the "hint" perspective makes a lot more sense,
because certificate chains are not generally built on the fly to
comport with the negotiated parameters.  So "send what you have"
and let the peer accept/reject makes more sense to me.

-- 
	Viktor.