Preview of our upcoming Root Ceremony

Issuance Tech
1

Hi everyone! It's 2025, which means that ISRG Root X1 is a decade old and ISRG Root X2 is five years old. As such, we're now in the midst of planning the key ceremony which will generate our next generation of root and intermediate certificates. We'd like to share our plans with you today, to get your feedback on the plan and to see if your eyes can catch any potential gotchas that our designs and linters have missed.

The 2025 ceremony will include:

  • The creation of a new RSA 4096 root, named Root YR
  • The creation of a new ECDSA P-384 root, named Root YE
  • Cross-signs of each of those new roots from our old roots, ISRG Root X1 and ISRG Root X2
  • A renewal of the cross-sign of ISRG Root X2 from ISRG Root X1, for maximum compatibility
  • Three new 2048-bit RSA intermediates under Root YR, named YR1, YR2, and YR3
  • Three new ECDSA P-384 intermediates under Root YE, named YE1, YE2, and YE3

You can see preview versions of all of these certificates, in both text and PEM formats, here: ceremony-demos/outputs/2025 at 2025-configs · letsencrypt/ceremony-demos · GitHub

We welcome feedback on all aspects of the above, from glaring issues we're somehow blind to, to the smallest nitpicks. Thank you in advance!

For a little bit of background on what's changing between our previous hierarchies and this new one, read on:

  1. We are generating two roots instead of just one at a time. This will allow us to move our RSA and ECDSA (and potentially future post-quantum) hierarchies forward in lockstep, without having to worry about different ages and levels of ubiquity between them.
  2. Thanks to this generational approach, we've also adopted a new naming scheme. This new generation of our hierarchy is designated as "generation Y" (appropriately following our current "generation X"), with the roots named "Root YR" and "Root YE". The intermediates under each of those roots share their name plus a small integer, so the intermediates are named "YR1", "YR2", etc. Because we'll be able to reset the intermediate numbering every time we issue a new generation of roots, we expect the numbers to stay smaller than our current intermediate "R14".
  3. Speaking of names, we're shortening those. Our new roots have a Subject Organization Name of simply "ISRG" (rather than the much longer "Internet Security Research Group"), and we have dropped the redundant "ISRG" from their Subject Common Names. This is part of our constant effort to minimize the number of bytes transmitted during every TLS handshake, to help save global bandwidth.
  4. The cross-signs onto these new roots have 7-year validity periods, rather than the 5-year validity period used by our prior X2-by-X1 cross-sign. This is so that the cross-signs won't be quite on the verge of expiring when the time of our next root ceremony (presumably 2030) approaches.
  5. We are not cross-signing the intermediates directly from ISRG Root X1, unlike our current ECDSA intermediates. Although this will increase the size of TLS handshakes, it is necessary that the chains presented by servers chain up to both our new and old roots, so that they will be trusted both by user-agents which don't yet trust the new roots and by faster-moving user-agents which remove trust in the old roots as soon as the new ones are distributed.
  6. Finally, none of the new intermediates assert the tlsClientAuth Extended Key Usage. This is necessary for acceptance into root programs whose policies require that new applicant hierarchies be serverAuth-only as of this year. This means that all Subscriber certificates issued by this hierarchy will be serverAuth-only, as we already announced.

Thanks again,
Aaron Gable
on behalf of Let's Encrypt

15 Likes
2

Generation X, always deemed to be forgotten...

On a serious note, and I hate nitpicking this... "Ye" is the current legal name of a celebrity formerly known as "Kanye West". I wouldn't be surprised if there is eventually some PR events or pop culture news relating to this overlap in names, and that may be something ISRG wants to avoid. Perhaps not. Given the new standardized naming scheme, and only having "Z" left in the alphabet, perhaps adopting "Generation B" (or other) now might be worth consideration.

6 Likes
4

Keeping the numbers might be a better idea. You can have RootY1 and RootY2, and name intermediates just Yn with odd n signed by Y1 and even n by Y2. (or mod for future and post-quantum... that kinda requires an advance decision on how many roots to have, tho.) (at that point not starting from 0 sounds wasteful, there's only 10 numbers that are one char long)

1 Like
5

Also the first thing that came to my mind unfortunately. I understand that tech and pop aren't that intricately related, but I'd urge LE to reconsider, even if X.. Y.. Z.. feels logical. But then, what after Z?

4 Likes
6

and if LE make new set of PQC chains in 2028 will they still gen Y or it start gen z?

2 Likes
7

How about Root 25E and Root 25R?

(When first reading, I already assumed "Y" stood for "year". :slight_smile:)

A hypothetical 2028 PQC Root could then be called 28M for, say, ML-DSA, without breaking the logic.

4 Likes
8

ML-DSA and SLA-DSA , so M ans S, but IIRC they mentioned they are open to using something stateful like LMS or xmss to reduce root signiture size more.

1 Like
9

Does this mean that future (default) chains will de facto become longer?

EE cert <= Intermediate <= Agile Root <= Legacy Root

with the last (cross) signature optional, to serve legacy and/or non-browser clients?

3 Likes
10

I understand that you also see the contradiction here. I suggest to generate intermediates from the old root certificates too, and allow the users to select them via alternate chain.

11

Does section 4.2.2 of the baseline requirements Latest Baseline Requirements | CA/Browser Forum which prohibits internal names in the common name field also apply to intermediate certificates?

12

R11 or E6 isn't really descriptive by itself, so I think that is already sorted.

13

That chain would actually make least sense, with browsers soon distrusting older roots.

14

You're brave, posting an invitation like that on the Internet. :slight_smile:

Hmm, what came to my mind was "Ye Olde Shoppe" type spelling. And "YR" made me think of a pirate's "Yarr!", or maybe Lt. Yar.

I do like this sort of thing better, though 2-digit years still make me twitchy (At the rate the industry is moving, Let's Encrypt will still need to make RSA roots 100 years from now to support legacy clients, right?). But date-as-versioning seems to be catching on in a number of places, and may have some advantages.

Is there a shortage of numbers I'm unaware of? It sounds like you're trying to stay within 3 characters, sure, but just incrementing a number seems simple enough, at least until you get to 100.

Last time we were nitpicking the names, I kind of liked giving them actual "names" if we were going to need a name at all. Even within three characters, there are plenty of names one could use that would be memorable. Ivy, Ava, Leo, Eli, Ian. Kai, Max, Ann, Dee, Joy, Sue, and that's just with a quick search. And I still think allowing donators to get premium "shiny" pokemon or other pop culture names for their intermediates isn't the worst fundraising plan out there. (Or maybe to get shorter single-character intermediate names? An emoji-named intermediate like CN=🔐?)

Moving away from the silliness of choosing names by committee here, and onto some actual technical questions:

I would like to hear the reasoning for continuing to use P-384 for intermediates instead of P-256. Especially if the security of 2048-bit RSA is acceptable for the length of time the intermediates are expected to be in use, and P-256 is generally much more performant and studied. See @Nummer378's commentary from the prior round of intermediates. We also had a thread here a couple months ago where a user had to switch to RSA because the system they were communicating with couldn't handle P-384 signatures but maybe could have handled P-256 better.

And if the answer is that the added cost of P-384 is just worth it for a longer-lived key like an intermediate, why wouldn't that same logic apply to the RSA side and mean a longer key than 2048 ought to be used there as well?

So, you used to have two of each (one for main use for the expected lifetime, and one for a "backup" which has never been used. The last time around, you made five of each, primarily using two in a "random" fashion and leaving three initially unused. There was some talk of intentionally switching to some of those unused ones after a year or two, but that doesn't look to have happened. What's the reasoning and plan behind having three this time around? I don't know as I particularly object regardless of the number there ends up being, just being nosy and curious about a change. Would it still be two in active use initially, with the third as a backup?

I'd love to know an estimate for how much bandwidth this change will save the Internet per year.

This surprises me (and as @bruncsak mentions, seems counterproductive to the goal of minimizing handshake sizes). What user-agents are you thinking of that would remove ISRG Root X1 and/or X2 while adding these new roots? I'm not aware of any that removed X1 when you added X2. There's nothing special that Let's Encrypt is doing here compared to other CAs, right? Do other CAs plan on only having one generation of roots in trust stores at a time and expect their sites to always send cross-signs from the prior generation?

Thanks!

7 Likes
15

Web browsers are starting to distrust older roots, and intend to limit Root CA lifetime to 15 years.

So you may end up with an incompatible client base, where older clients trust Root X1 andX2, but not the newer roots yet, and newer/stricter clients distrust Root X1 and X2, and only trust the newer, "agile" roots. Cross-signing the newer intermediates directly from the older roots skips one set of client, and issuing only from the newer roots skips another. So you need a legacy-to-agile-root cross-sign (see my post above) to satisfy both types of clients.

4 Likes
16

Okay, but ISRG Root X1 is only 10 years old. So for the next round of roots generated in 2030 I could see needing to figure out how many systems supported X1 but not newer roots in order to know if systems would need to send cross-signs, but I wouldn't think it'd be an issue for this round. Unless I'm missing something, which is entirely likely.

3 Likes
17

4.1.2 Root CA Succession Planning

CA Owners SHOULD request for the replacement of a certificate included in the Chrome Root Store no later than 5 years after the release date of the Chrome Root Store's initial inclusion of the certificate.

….

The CA certificate being replaced will be removed from the Chrome Root Store upon the absence of unexpired and unrevoked TLS server authentication certificates

Chrome will remove X1/X2 once YR/YE are trusted and all certificates have been replaced, so servers will likely need to serve both an older root (Gen X now) and a current root (Gen Y).

In 5 years (2030), we will issue Gen Z roots. At that time, we expect Gen Y to be fully trusted, and so the default chain will switch to Gen Y and Gen Z, with Gen X still available if needed, but the chain will be getting longer. 5 years after (2035) that we will issue a new Gen A. X1 will expire and no longer be available. Users can chain to X2, A, Z or Y depending on their needs.

We also expect technology like TLS Trust Anchor Identifiers will help avoid overly long chains as well.

I also expect we will add a post quantum root during the period which the “Y” roots are current. I can’t say for sure, but if it’s an MLDSA root, I would expect that to be root YM. It will not be issued until at least 2026, if not later.

Depending on advances in Quantum Computing, we may begin deprecation of the RSA and ECDSA roots, but the timeline for that is unknown.

6 Likes
18

The problem is that the baseline requirements defines an Internal Name as

A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA’s Root Zone Database.

As YE1, YE2, YE3, YR1, YR2 and YR3 are valid domain names but are not in the root zone database, they would qualify as internal names if they were in the Common Name field.

19

@MaxHearnden I can't literally find the "definition trail", but I'm quite sure it's fine to have whatever name you like for intermediate certs. Otherwise most if not all intermediates currently in use by most if not all publicly trusted CAs would be in trouble.

2 Likes
20

I don't understand all the twists and turns in chapter 7 but I think that is where this is covered

Note this in BR history

v1.4.8 Ballot 199
Require commonName in Root and Intermediate Certificates
Adopted: 9-May-2017
Effective: 8-Jun-2017

2 Likes
21

Perhaps the roots could be written with an appended "0":

  • YE0 creates YE1, YE2, YE3, ...
  • YR0 creates YR1, YR2, YR3, ...
3 Likes