ECDSA Root and Intermediates


As the “Embed SCT receipts in certificates” feature is almost complete, I had a some questions about the preparation of the next one: “ECDSA Root and Intermediates” with the ETA Q3 2018 according to

Before the generation of the publicly trusted Root and Intermediates, do you plan:

Will the new root (or intermediates) be cross signed with “ISRG Root X1” ?
Will the new root (or intermediates) be cross signed with “DST Root CA X3” or another widely trusted root ?

I guess you planned to submit that new root to trust stores?

ISRG ECDSA Root Timeline
Switch intermediate certificate from IdenTrust to ISRG signed

Maybe @josh or @jsha could comment on this?


We hadn’t planned to publish a draft hierarchy before the ceremony, but that’s an excellent idea and we’ll do it. Thanks for suggesting it! We will also generate a fake version of that hierarchy and make it available on staging as you suggest.

Most likely the new root will be cross-signed by ISRG Root X1 and also submitted to trust stores directly. We haven’t yet decided about a DST Root CA X3 cross-sign.


If you choose not to cross-sign, how would a browser make a valid chain if ISRG Root X1 isn’t valid in that certain client?

LE Cross Signed Intermediate Certificate

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. :slight_smile: 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 still indicate an ETA for “Q3 2018” and “March 2018” =>

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. :slightly_smiling_face: 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?

Thank you


The ETA has been pushed back to Q1 2019:

ISRG ECDSA Root Timeline

Is the publication of the draft still planned?


Yep, still planned; thanks for the reminder!


Hi @jsha, any update on a draft publication?


No update yet, sorry!


Thank you, as long as Let’s Encrypt consults the community before signing the new roots I’m happy :smile:

I saw that the deadline was just pushed to Q2 2019:


Apparently it was just changed to Q3 2019:

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).

Sources: [1] [2] [3]


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 :slightly_smiling_face:

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!