Detailed 2020 hierarchy

[jsha]

@petercooperjr

I didn’t know if routing through X2 allowed browsers/validators to shortcut the top-level X1→X2 link once X2 was in their root trust store. That is, even if servers needed to serve a full X1→X2→E1→leaf chain to handle cases where only X1 was in the trust store, once one particular user’s browser was updated to trust X2 would it be able to do an only-ECDSA validation and then just ignore the signature by X1?

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.

@petercooperjr

My next question (I keep coming up with them I guess) is unrelated, but just based on the naming: Why would you include the key type in the intermediates’ names but not in the roots’ names? It seems a little weird to me that “ISRG Root X1” and “Let’s Encrypt Root X2” are part of the same “series” with the main difference being the key type

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.

@jvanasco

any chance that domain name might change to something that reads more like “encrypt”?

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.

[jsha]

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.

[jsha]

Update: We had our key ceremony yesterday! 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: https://letsencrypt.org/certificates/

[petercooperjr]

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?

[aarongable]

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