On 25/10/14 19:26, Julien Vehent wrote:
<snip>
I wonder if this is really useful though. Server Side TLS is a pragmatic
guide, and pragmatism dictates that operators should use SHA-256 certs,
not SHA-384 or SHA-512. When asked to review a production site that runs
a SHA-512 cert, I would recommend the admins to downgrade to SHA-256 to
prevent unknown behavior with unknown clients.
Sadly, SHA-512 certs (both CA and end-entity) don't work very well with
WebPKI TLS. Browsers typically don't specify RSA/SHA-512 and
ECDSA/SHA-512 in the TLS "signature_algorithms" extension. Some servers
interpret "signature_algorithms" as a full list of certificate signature
algorithms supported by the client. Rather than return a SHA-512 cert
to those browsers, such servers send a fatal alert.
<snip>
* ECDSA certs (and prioritisation of ECDSA above RSA) - there's no
mention of those, and since we suggest PFS over non-PFS and
ECDHE-ECDSA is over twice as fast as ECDHE-RSA[1], I think we
definitely should allow (if not recommend) its use
Same comment as above: we first need to evaluate compatibility of clients.
Having ECDSA in the recommended ciphersuites has no site effect on
server compatibility. But recommending ECDSA certificates does have
strong side effects.
Do you know of certificate authorities that issue ECDSA certs?
Yes. Comodo and Symantec definitely do, and I wouldn't be surprised if
several other CAs do by now.
CloudFlare's Universal SSL uses ECDSA certs exclusively, so as of a few
weeks ago there are now _a lot_ of ECDSA certs in the wild.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
