We could request a DST Root CA X3 cross-sign on ISRG Root X1, which would then pass on trust to the new ECDSA root. But details like these are a good reason to publish a draft before doing the ceremony. I’m going to be focusing on SCT stuff today, but will circle back to this soonish.
I’m not sure it’s technically/legally/contractually possible but a cross-sign from a Let’s Encrypt intermediate already cross-signed by DST Root CA X3 should is probably another solution (but maybe not a good one, as it’s add a level in the chain to send, which increase the handshake size, where one of the objective of ECDSA is to reduce it.)
Yes! Of course, it’s the priority without any doubts. These questions just needed to be asked before it was too late and some irremediable steps took place.
Thanks a lot for these answers, and all the awesome work you all do, making the internet a safer place!
What happens in 2021 when the IdenTrust root certificate expires?
Do you have a estimated timeline about it? (As https://letsencrypt.org/upcoming-features/ still indicate an ETA for “Q3 2018” and https://letsencrypt.org/certificates/ “March 2018” => https://github.com/letsencrypt/website/issues/323)
The CT, ACMEv2 and the TLS-SNI bug obviously has delayed your previsions. (Not a criticism, on the contrary, there is absolutely no reason to rush for ECDSA)
Hi, do you have any update on this topic? Upcoming Features page still lists ETA for Q3 2018, and it’s already Q3 2018. Thanks.
@jsha is cureently out for vacation… so I’m afraid he can’t answer anything until mid-auguest…
In the meantime, @josh might be able to help?
Is the publication of the draft still planned?
Yep, still planned; thanks for the reminder!
No update yet, sorry!
Thank you, as long as Let’s Encrypt consults the community before signing the new roots I’m happy
I saw that the deadline was just pushed to Q2 2019:
Apparently it was just changed to Q3 2019: https://github.com/letsencrypt/website/commit/696b1005ab354b37a477e657fe5ad465108ab321
ISRG ECDSA Root Timeline
Is there any reason to rush ECDSA when there are already standards for Ed25519-based certificates? There are known issues with both ECDSA algorithm and secp256r1 curve, such as the possibility of key leakage if the server is low on entropy and dubious curve constant source (with Bruce Schneier specifically recommending against using this curve because of it).
I think EdDSA would first need to be approved in the BRs, whereas ECDSA is already approved and more widely supported by FIPS 140-2 HSMs.
Is it very likely that approval will happen in a year from now?
In my opinion, there is no urgent need to create a new root certificate, an intermediate could suffice, since it won’t require changes on client side and the only time the RSA signature on ECDSA intermediate will be verified is when it is first encountered. Also, ECDSA signature verification is more resource-intensive than verifying a RSA signature of a similar security level.
Overall I agree that ECDSA should be an available option, but I don’t think there is any point for generating a new root certificate and go through the process of getting it added to each browser.
No reason to rush it at all. And I’m glad they prioritized a CT log over it, I was just noting the new deadline
I think I agree with you. I full chain seams more “clean” but may not be the most efficient thing to do. The lasts messages shows how important the discussion with the community could be important before LE signs new certificates. Those things shouldn’t be rushed!
More information here about the ECDSA timeline change: https://letsencrypt.org/2018/12/31/looking-forward-to-2019.html
“We had planned to add ECDSA root and intermediate certificates in 2018 but other priorities ultimately took precedence. We hope to do this in 2019. ECDSA is generally considered to be the future of digital signature algorithms on the Web due to the fact that it is more efficient than RSA. Let’s Encrypt will currently sign ECDSA keys from subscribers, but we sign with the RSA key from one of our intermediate certificates. Once we have an ECDSA root and intermediates, our subscribers will be able to deploy certificate chains which are entirely ECDSA.”
Increased security rarely adds efficiency.
In this case, I would trade the loss in efficiency for the increased security in the complete separation from RSA.
When completely separate, if/when ever there is a break in RSA it should not affect the ECDSA chain.
It’s possible to cross-sign ECC intermediary with both ISRG RSA root and upcoming ISRG ECC root. This will satisfy both requirements.
Also please do not use P-384, its implementation in OpenSSL is terrible:
$ openssl speed ecdsap256 ecdsap384 ecdsap521
256 bits ecdsa (nistp256) 0.0000s 0.0001s 29524.9 9531.8
384 bits ecdsa (nistp384) 0.0011s 0.0009s 874.9 1151.7
521 bits ecdsa (nistp521) 0.0004s 0.0008s 2510.6 1238.0
Old IE versions require ECC certificates for GCM cipher support (https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%207&key=143), so ECC root makes sense to implement.
I don’t see as much of a decrease on one system:
256 bit ecdsa (nistp256) 0.0000s 0.0001s 24702.2 10604.2
384 bit ecdsa (nistp384) 0.0002s 0.0008s 5288.4 1258.6
521 bit ecdsa (nistp521) 0.0005s 0.0010s 1957.2 982.2
But I do see a similar very significant difference on another:
256 bits ecdsa (nistp256) 0.0000s 0.0001s 26444.8 7264.5
384 bits ecdsa (nistp384) 0.0019s 0.0011s 534.0 930.4
521 bits ecdsa (nistp521) 0.0036s 0.0023s 275.8 425.7