24

I looked around, and all I see is websites using RSA2048 for Root signature, and a few using ECC for encryption.

Are there any reasons folks don't seem to use ECC for TLS root signature?

Are there any drawbacks to using ECC for X.509? - if indeed it's possible?

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
Woodstock
  • 679
  • 6
  • 20
  • For sites where the site's certificate is signed by an intermediate certificate, and the intermediate certificate is signed by a root certificate - I've seen several cases where the site's certificate is signed by the intermediate certificate with ECDSA. But, I've never seen a case where the intermediate certificate is signed by the root certificate with anything other than RSA. – mti2935 Mar 25 '20 at 16:58
  • Interesting thanks, there is no technical reason why one couldn't use pure ECC without RSA for certs/X.509 right? @mti2935 – Woodstock Mar 25 '20 at 16:59
  • 9
    There is no technical reason why it couldn't be done. I think it's more to do with logistics. Root certificates are installed on the client. In order for a root certificate to sign another certificate using ECDSA, the root certificate would need to have an ECC public key. I just checked a handful of the root certificates installed on my system, and all of them have RSA public keys. So, it would be a matter of clients migrating to new certificates. – mti2935 Mar 25 '20 at 17:12
  • Thanks, if you want to add an answer I will mark as correct, appreciate your time @mti2935 – Woodstock Mar 25 '20 at 17:14
  • Speaking as someone who's tried using ECC for SSL certificates, it can be a bit of a crapshoot which curves a particular client or library will support, and this can change in new versions with little warning. – James_pic Mar 26 '20 at 12:29
  • My contribution to the ECC case. The most common reason why many people do not use ECC for encrypting traffic is due to support. Most systems use RSA, as sort of the default. RSA is proven to work and is easy to understand and setup. ECC is much different method, which also works, but many people have difficulty understanding, much less securely implementing it. This no different than the Windows MacOS issue. Both systems are good, but people tend to make choices based on patterns. – user242063 Sep 01 '20 at 16:31

3 Answers3

38

There's a slide deck on NIST by Rick Andrews, Senior Technical Director and Distinguished Engineer of Symantec, titled Symantec’s View of the Current State of ECDSA on the Web (published 2015) providing great insight:

What is holding back the market for ECDSA certs?

  • Legal/IP concerns were not allayed by the 2003 NSA-Certicom license
  • Distrust in Suite B curve choices after Snowden, especially in Europe
  • Lack of client support (Windows XP and non-traditional devices like smart TVs and Japanese feature phones)
  • RSA isn’t broken; risk of trying new algorithm; general lack of awareness
  • Lack of dual-stack support in web servers (except Apache – see http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#comment_970)
  • Clients supporting ECDHE may not have ECDSA root; difficult for servers to know
  • ECDSA root may not be EV-enabled
  • Client-side performance penalty (ECDSA slower than RSA for signature verification for commonly-used key sizes)
  • "Heard there was some technical problem with ECDSA" – (if a cryptographically secure random integer is not selected, the private key can be determined)

Impact of New Curves

  • Impact will likely be muted if IP issues are not cleared up
  • CAs need support in their HSMs and software toolkits
  • CAs will most likely sign keys from new curves using existing P256 or P-384 roots, to avoid delay of deploying roots using new curves
  • Signing with existing RSA roots or intermediates carries IP risk, but mitigates root ubiquity issue
  • Even though CAs may not initially create intermediate CA certs with new curves, we need to perform Proof of Possession of key. Usually done by checking signature on CSR, requiring support of new key curve in the CA’s HSMs and software toolkits.
  • Browser and web server vendors must support new curves
Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
phbits
  • 1,002
  • 2
  • 5
  • 12
  • 2
    Great find!! This is the canonical answer and should be accepted! – Mike Ounsworth Mar 25 '20 at 17:56
  • It seems the comment you were linking to has been removed. – Ángel Mar 26 '20 at 22:27
  • 2
    I see FUD spreading in a number of points and I'm not qualified to judge the rest. Most importantly, [people have trust issues](https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/) when it comes to Symantec's CA expertise. – kubanczyk Mar 27 '20 at 10:13
26

TL;DR: There is nothing technically wrong with ECC; in fact it has better bandwidth and server CPU load than RSA (but higher CPU load on browsers, thanks @CodesInChaos), but for historical reasons it just sorta never got adopted.

Disclaimer: I work for Entrust Datacard

Entrust is one of the publicly-trusted CAs, and we have separate publicly-trusted PKIs (root + intermediates) for RSA SHA-1, RSA SHA-2, and ECC P-384. See the Entrust Root Certificates Download page.

The compatibility table on that page also answers your question about why ECC never really took off: clients / browsers / OSes were slow to adopt ECC. There was a time period where NIST and other agencies were urging people to move to ECC, but website admins were hesitant because of backwards compatibility issues. Now, even though virtually everything understands ECC today, it kinda just never took off.

Also, the NSA had been one of the big pushers of ECC, but in August 2015 they released a statement (source: wikipedia):

"Unfortunately, the growth of elliptic curve use has bumped up against the fact of continued progress in the research on quantum computing, necessitating a re-evaluation of our cryptographic strategy." NSA advised: "For those partners and vendors that have not yet made the transition to Suite B algorithms, we recommend not making a significant expenditure to do so at this point but instead to prepare for the upcoming quantum resistant algorithm transition."

So anyone who was still contemplating migrating from RSA to ECC now had zero reason to spend the effort.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 8
    ECC has better speed for signing but is slower than RSA for verification. The server certificate is the only one which signs often enough for performance to matter. (The size advantage applies at all levels) – CodesInChaos Mar 25 '20 at 21:18
  • 3
    @CodesInChaos The 2048-bit RSA is the weakest link on the current commodity devices, so needs to go away at some point in the future. And I don't think that 3072-bit RSA verification performance can beat ECC's. – kubanczyk Mar 27 '20 at 10:20
15

It's uncommon to see a signature by a root certificate using ECDSA, because most root certificates contain RSA public keys, not ECC public keys. Moreover, because root certificates must be installed on client devices, updating certificates and/or adding new certificates has its logistical challenges. But, as Mike Ounsworth points out in his answer, there are some root certificates that have ECC public keys, such as the Entrust Root Certificate Authority—EC1 certificate.

yoozer8
  • 810
  • 2
  • 7
  • 17
mti2935
  • 19,868
  • 2
  • 45
  • 64