Detailed 2020 hierarchy

That’s correct. Another way of putting it: The chain offered by the server is purely informational, and clients will build their own path to a trust anchor. Clients that have X2 in their trust store would potentially save an RSA verification, depending on what path they build.

Also, once X2 becomes ubiquitous (in a while), servers could offer the plain E1->leaf chain.

It’s true, this is weird and not consistent. Naming is hard, though, and this is what we’ve settled on for this round.

When we adopted X1 for our original root and X1-4 for our original intermediates, I think we were just following the example of DST Root X3; I don’t know the origin of that naming scheme.

For the new root, I’m following the example of our X1 root, which will live a long time, and not worrying about the naming scheme of the X1-4 intermediates, since they are not long for this world.

Our criteria were: under .com, .net, or .org; short; evocative of Let’s Encrypt. I’m pretty sure all the four-letter ones are taken. lencr seemed reasonably close in the five-letter range.


Just made another update: Thanks to the awesome zlint project, we noticed a mistake in this plan: The intermediates we were issuing did not include the digitalSignature keyUsage, which is needed for signing OCSP responses. I’ve updated the demo repo, and I’ve regenerated the sample hierarchy and updated the top post in this thread.


Update: We had our key ceremony yesterday! :tada: We actually decided to use “O = Internet Security Research Group, CN = ISRG Root X2” as the name for our new ECDSA root, for consistency with our existing ISRG Root X1.

The new certificates are disclosed in CCADB, and are also published here, along with a beautiful new diagram of our hierarchy from @aarongable:


Thank you!

Is there a new “fake” hierarchy for the staging environment as well?
Is there a timeline of roughly when these new intermediates will start being in service and used for signing leaf certificates?


We have not yet received cross-signs from IdenTrust on the new R3 and R4 intermediates; we won’t be putting them into service until after that happens. Similarly, there are a few pieces of due diligence (e.g. issuing valid, expired, and revoked example certificates to comply with BRs 2.2) we have to do before we’re ready to start issuing with the new ECDSA hierarchy.

I don’t think we have a strict timelime for when we expect that work to be done, other than “as soon as practical”.


3 posts were split to a new topic: Key sizes for new intermediates

A post was split to a new topic: ECDSA issuance in staging