Why don't folks seem to use ECC for TLS root certificate signature?
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
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.
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.