Detailed 2020 hierarchy

I’m wondering if there’re two root certificates named Let’s Encrypt Root x2, one is self-signed, the other is signed by ISRG Root x1.
Do we have a plan to submit the self-signed one to the major browsers and OS(like Windows, Java,etc.,)?

Is it possible to use sha384WithRSAEncryption or 4096 bit keys to protect the new int-r3 and int-r4 certificates? I think it could provide a better safe protection.

2 Likes

Every root cert is self-signed.

i guess the new CA will be submit to the different major browsers soon after it is created.

2 Likes

I think I understand what’s happening; please correct me if I get something wrong.

X2 is a brand new root. It’s going to end up getting published to the various browser/OS/etc root stores, after which both the existing X1 and the new X2 will be the true real ISRG/Let’s Encrypt roots, and both will be valid normal roots, it’s just that one is RSA and one is ECDSA.

X1 is the existing root, which hasn’t been used for most purposes directly since it takes time to get into all the root stores, but now it’s been 5 years and is in most places so it can start getting used.

So, in the short-to-medium term (whenever they start using these new certificates, which I think is within the next few months?), RSA leaf certificates will get signed by R3 (or R4), which will be signed by X1. ECDSA leaf certificates will get signed by E1 (or E2), which will be signed by X2, which will be signed by X1.

Longer-term, some number of years from now, once X2 is trusted everywhere that X1 is now, you won’t need that last signature for ECDSA certificates. So leaf ECDSA will get signed by E1 (or E2), which will just be signed by (the self-signed version of) X2.

Did I get that all right?

5 Likes

by the way why root cert need to expire at all? If it’s not secure enough like private key leak or crypto break it will removed from trust store, and if it’s still secure but it expired then it will only cause problem to clients.

5 Likes

You did a great job explaining things, @petercooperjr! Thanks for that. :slight_smile:

Also worth noting, since we mentioned it in previous posts but not here: We're planning to also get a signature from DST Root X3 -> R3. That will help current Let's Encrypt subscribers who need the additional compatibility provided by that root. They can configure their ACME client to select an alternate certificate chain provided by the server. But that will only be good for about a year because DST Root X3 expires in 2021.

To put this question another way: Currently "Let's Encrypt Intermediate X3" has a 2048-bit key. R3 and R4 will also have 2048-bit keys. Should it be longer? In my opinion, no. Longer keys for our RSA intermediates significantly increase the size of the certificate chain served. And based on currently available knowledge, I believe 2048-bit RSA keys should be safe against factorization for the lifetime of these certificates (5 years).

5 Likes

Thanks, I’m glad I’m understanding. So now I have a question, which is really just out of curiosity: If it takes around 5 years before you can rely on root trust stores having a new root, and these intermediates have lifetimes of around 5 years, why would one have E1/E2 signed by X2 rather than X1? That is, if you need to chain up to X1 for the next 5 years or so anyway (and so you can’t really have a full-ECDSA chain until the next set of intermediates comes along), what’s the advantage of the added step in leaf→E1→X2→X1 over leaf→E1→X1? Especially considering the efforts being made here to squeeze every last byte possible (including a custom URL shortener‽) to allow servers to present smaller certificate chains, I’m just assuming I’m missing what the benefit is of the extra layer.

I’m far from being a PKI expert, so I’m just trying to learn what’s going on and why. Thanks!

3 Likes

Good question! Mainly the folks who have been interested in an ECDSA hierarchy have wanted an all-ECDSA hierarchy, but it's true that at first deployment they would not be able to get that and would need to serve the chain that goes through X2. However, signing X1 -> E1 would give shorter chains for such users. Will think about it! BTW, I tend to use the notation from RFC 4158 - Internet X.509 Public Key Infrastructure: Certification Path Building, where an arrow indicates the direction of signing.

FYI lencr.org is not a URL shortener. It's just another hostname that we control and will configure to directly serve the relevant resources.

3 Likes

Heh. Wouldn’t be the first thing I’ve done backwards. I’ll see if I can remember to draw arrows from root to leaf from now on since that’s the “standard”. :slight_smile:

One possibility that occurred to me was 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? Which might make things faster for those users than a chain that includes RSA? Or is that not how it works since X2-signed-by-X1 is “different” from X2-signed-by-itself-in-the-trust-store?

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 (though it wouldn’t be obvious from looking in a list that they’re from the same entity since the ISRG brand isn’t nearly as well-known as Let’s Encrypt), but the intermediates are distinguished by key type where it’s obvious if I’m talking about the RSA one or the ECDSA one. Separately, there already exists a “Let’s Encrypt Authority X2” listed as retired which seems like it could cause confusion since “Let’s Encrypt Root X2” and “Let’s Encrypt Authority X2” sound similar if one isn’t paying close attention (though I don’t know if it would actually cause any issues in practice). I guess I want to know what the “X” stands for. (And I do understand that naming things is the hardest problem in software engineering by far.)

3 Likes

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

4 Likes

I assumed it was for X.509

2 Likes

🔒.org ? (xn - - lv8h . org)

“This ending .ORG doesn’t support this combination of international characters”

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.

6 Likes

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.

12 Likes

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: https://letsencrypt.org/certificates/

15 Likes

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?

6 Likes

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

8 Likes

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

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.