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

[Yoav Nir <[e-mail]>]

> On Jul 8, 2015, at 9:27 PM, Viktor Dukhovni <[e-mail]> wrote:
> 
> On Wed, Jul 08, 2015 at 09:08:39PM +0300, Yoav Nir wrote:
> 
>> It's possible that a single user might be issued multiple certificates,
>> but they will be from different CAs, and choosing a client certificate
>> based on CA will work. I don't see any use case for a corporate CA to
>> issue multiple certificates to the same user or device with different
>> algorithms. This is at least true for my use cases.
> 
> Are root-CA self-signatures subject to the algorithm compatibility
> requirements on intermediate and leaf certificates?  I was under
> the impression that root-CA self-signatures were exempted from such
> a constraint.

Root CAs are not subject to any restrictions.  What I meant was that the same user (or more to the point - the same device) can have multiple certificates from multiple CAs for multiple applications. For example, the user’s employer might have a corporate portal with user certificates issued by the corporate CAs. Her employer may have also deployed an SSL VPN solution that uses its own bundled CA to issue certificates, and maybe the user’s bank also issues certificates (there were a few of those in the 90s and early 00s, but they have mostly given up on that).  

Choosing which of these certificates to use is easy - the CA DN is in the certificate request, and each portal asks for exactly one CA. 

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.

Yoav