Michael StJohns wrote: > Martin Rex wrote: >> oops, typo: >> >> Martin Rex wrote: >>> Actually, looking at the DigiCert issued ECC cert for www.cloudflare.com >>> I'm a little confused. >>> >>> This is the cert chain (as visualized by Microsoft CryptoAPI): >>> >>> server-cert: CN=cloudflare.com, ... >>> contains ECDSA P-256 public key >>> is allegedly signed with sha256ECDSA >>> >>> intermediate CA: CN=DigiCert ECC Extended Validation Server CA >>> contains ECDSA P-384 public key >>> is allegedly signed with sha384RSA >>> >>> root CA: CN=DigiCert High Assurance EV Root CA >>> contains RSA 2048-bit public key >>> is self-signed with sha1WithRsaEncryption >>> >>> For those who insist on reading rfc5246 verbatim, this chain requires >>> >>> ECDSA+SHA384:RSA+SHA384:RSA+SHA1 >> ECDSA+SHA256:RSA+SHA384:RSA+SHA1 > > I don't think RSA + SHA 1 is actually required. The Signature over the > trust anchor (root CA) is basically a no-op - assuming the certificate > is in the browser(client) trust store. The trust is traced to the > public key regardless of the form in which it's provided. We use > self-signed certs a lot to carry the public keys and names (and > sometimes constraints), but that's not required by PKIX.
A server TLS implementation is *ALLOWED* to unconditionally include the RootCA cert, and in that case a client not sending RSA+SHA1 clearly indicates DO NOT SEND ME THAT PATH if the bogus words in rfc5246 about signature_algorithms is taken literally. Remember that were talking about *SERVERS* preempting the clients decision (like Microsoft SChannel implemented it), not clients ignoring certs sent by the server for policy reasons. A server implementation refusing to send such a cert chain to a client that doesn't include RSA+SHA1 (and blaming DigiCert for it) is equally justified than Microsoft SChannel choking on absent signature_algorithm extensions. The only reasonable interpretation of that part of rfc5246, is to completely ignore it. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
