On Fri, Mar 24, 2017 at 1:23 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > On Mar 24, 2017, at 1:08 AM, Martin Thomson <martin.thom...@gmail.com> > wrote: > > > >> I've never seen > >> a TLS server that has multiple chains to choose from for the same > >> server identity. > > Both chains of course use SHA256. > > Sorry I meant to say multiple digest algorithms for otherwise > identical chains (same public key algorithm and server name). > > Even in the SMTP space some servers have both RSA and ECDSA certs. > When that's the case, cipher negotiation ensures that the selected > EE certificate's public key algorithm is mutually supported. > > There's still little need to pay attention to the client's signature > algorithms in choosing the EE-certificate and associated chain. > Cloudflare does with the SHA-1 and SHA-256 support ( https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/ ) Google has a certificate chain that supports only SHA-256 (if you trust GeoTrust) or which supports SHA-256 and SHA-1 (if you only trust Equifax, and require the cross-sign). For example, OpenSSL without the ALT_CHAINS fix of 1.0.2 would prefer the Equifax path over the GeoTrust path. There are plenty of large CAs with complex cross-signs that introduce additional digest algorithms at the intermediate level, and the server can influence that path validation by using the signature algorithms (although few do). I would say that the vast majority of servers deployed on the Internet using commonly publicly trusted CAs have more than one chain to choose from - often dependent on the installed trust anchors - but the servers may simply not be aware of it, and relying on clients to do the needful (for example, with AIA fetching). The delta of sites that don't work in Firefox (when SHA-1 is disabled) compared to Chrome (when SHA-1 is disabled) illustrate this - as Chrome performs the AIA fetching to find the alternative SHA-256 paths, while Firefox does not, and requires the server supply them. Similarly, a given server may have paths where the leaf uses SHA-256, but intermediates use either SHA-256 or SHA-384 dependent upon the trust anchor it is rooted in.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
