Viktor Dukhovni wrote: > > The net effect is that in practice you simply ignore the signature > algorithms when it comes to the certificate chain.
Essentially correct. This is the only reasonable, highly backwards compatible and perfectly secure choice. > > I've never seen a TLS server that has multiple chains to choose from > for the same server identity. This applies also to TLS 1.2, despite > RFC 5246. Servers with multiple chains for the same server identity have been around for a while, and their number might be higher than you expect. More often they choose cert by offered cipher suites (RSA vs. ECDSA), rather than by signature_algorithms. I have recently encountered three public CAs that issue such dual-certs, two of them either thought about potential consequences (or got it right by chance): VeriSign and DigiCert. * The RSA and ECDSA dual server certs from VeriSign were issued under the same (RSA) RootCA cert "VeriSign PCA3 - G5", * The RSA and ECDSA dual server certs from DigiCert were issued under the same (RSA) RootCA cert "DigiCert High Assurance EV Root CA" However, the RSA and ECDSA dual server certs from Comodo were issued under _distinct_ RootCAs. I don't know whether Comodo or the purchaser of the dual server certs goofed this, but unless you negligently dump an overbroad "blindly trust everyone" into your client-software in a web-browser fashion (which gives _everyone_ the creeps, see Certificate Transparency and HPKP bandaids), those Comodo-issued RSA+ECDSA dual server certs from distinct PKIs are a severe interop nightmare. If you want to roll out support for ECDSA cipher suites into an installed base of TLS that is currently limited to RSA, dual certs from distinct PKIs may result in servers unexpectedly picking and responding with an untrusted server cert in existing usage scenarios, after a software update of the TLS client (which adds support for ECDSA cipher suites). Two Cloudflare (CDN) examples for dual cert servers: Comodo: https://regmedia.co.uk/ DigiCert: https://www.cloudflare.com/ Actually, the latter seems to be a triple-cert server (try -sigalgs RSA+SHA1) Things could be so much easier if folks would spend a little more time thinking about backwards compatibility, i.e. what is necessary so that a new feature can be rolled out into an installed base of TLS client and servers, without causing interop failures for existing usage scenarios. TLSv1.3 has a few problems. Including the pointless hiding of ContentInfo in the outer TLS record, which is non-interoperable with some of the installed base and precludes efficient end-of-communication discovery. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
