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?

6
  • 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, 2020 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, 2020 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, 2020 at 17:12
  • Thanks, if you want to add an answer I will mark as correct, appreciate your time @mti2935
    – Woodstock
    Mar 25, 2020 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, 2020 at 12:29

3 Answers 3

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.

0
39

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
3
  • 2
    Great find!! This is the canonical answer and should be accepted! Mar 25, 2020 at 17:56
  • It seems the comment you were linking to has been removed.
    – Ángel
    Mar 26, 2020 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 when it comes to Symantec's CA expertise.
    – kubanczyk
    Mar 27, 2020 at 10:13
27

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.

2
  • 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) Mar 25, 2020 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, 2020 at 10:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .