I just read about the new roots and that you are planning to begin issuing under these as early as 2026, while there are still ten years left on the ISRG X1, which only recently got out of a cross-sign itself. That means a lot of sites will have to rely on a cross-sign again to keep supporting older devices. Saving a few bytes on the name won't do much if sites have to transmit a longer chain and not doing that feels like actively supporting planned obsolescence. I think you shouldn't issue from the new roots until 2030 or at least have all intermediates signed by both roots, so people can opt to use the old chain without having to throw in an additional root-intermediate.
I think Google does it in a similar why for the WR1
that Intermediate is only signed by GTS Root R1
which itself ist cross signed.
Our root X1 is about 10 years old now. Some root programs (like Mozilla) have a 15-year age limit on root keys. So we do need to begin transitioning from our X roots to the new Y ones.
So we need to start getting new roots trusted.
Some root stores (like Chrome) will begin removing the X roots once the Y roots are trusted, so having intermediates signed by both roots won’t work. I expect by sometime in 2027 (maybe even 2026), more users will trust the Y roots than the X ones, at least in browsers.
8 Likes
Thanks for the insight. I was indeed expecting the X1 to stay trusted until its expiration date in 2035. Unfortunately many devices do not allow updates to the trust store independent of system updates, but understand you can do nothing about that.
In addition, the Chrome Root Program explicitly wants a five-year rotation period:
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.
3 Likes
This is why our Chains of Trust page lists "trusted until", rather than the notAfter date.
4 Likes
So it's sounding like this is going to need to be the standard approach from most CAs, of having longer chains in order to handle the needs of systems that update roots quickly as well as systems that update roots slowly. It might be helpful for explaining this if someone in the community came up with examples of how other CAs are doing the same thing (either now or with plans to do so). Though it might be that Let's Encrypt is more public about their future plans than other CAs are, even if other CAs are internally making the same kinds of plans.
4 Likes
Okay, but that's crazy if there's no reason to believe the key has been compromised. If that becoms the norm and older certificates are distrusted almost immediately after a new one has been created, the whole system becomes incredibly fragile. I'm really worried about the centralization forced upon us by the big tech companies. It feels like the CA system is becoming just another tool for them to force people to always stay on edge, keep buying and excert control. The CAs have to do all the work while the Trust-Store-Overlords make all the decissions, and site administrators have to just go along. I thought the purpose of root certificates was to stay valid for a long time. That's why we have intermediates after all, so that if anything happens to them, they can be easily replaced and the root keys can stay tucked safely away.
I think it makes more sense in a world where we're rapidly approaching transitions to quantum-safe key material and signature algorithms, or worse, rapidly approaching practical attacks on classical keys and algorithms. The root programs need both CAs and server operators to have serious agility, in order to continue protecting their users.
Regardless, that's a discussion better had in forums where root program representatives are present, like MDSP.
6 Likes
What's the default chain going to look like for ECC leaf certificates?
From New "Generation Y" Hierarchy of Root and Intermediate Certificates - Let's Encrypt, it looks like it will be EE < YEn < YE < X2 < X1 ?
Or will there be a YE < X1 cross-sig as well, to make a shorter but still widely compatible default chain?
1 Like
Correct. YE will need to go via X2 to chain to X1.
You can see the full docs in a PR at Update Certificates doc to show issuance from Gen Y hierarchy by aarongable · Pull Request #2068 · letsencrypt/website · GitHub
which has an expanded diagram:
Chains of Trust - Let's Encrypt
5 Likes
Well, if that's the case then Let's Encrypt really doesn't have to bother with confusing root/intermediate common names IMO, if the chain is huge anyway.. A few bytes here and there will be a very small percentage of the entire chain size.
I'd rather have useful names TBH.
R vs. RSA.. E vs. ECDSA.. Just two to three bytes extra. And maybe just call it "RSA Root 2025" and "ECDSA Root 2025". No nonesense, no need to go XYZ -> ABC, all those nonsensical, nondescriptive letters. Just sensical, logical names.
Also, most of the traffic on the internet is spam anyway, so why bother 
While I appreciate your point, names like you suggest aren't quite as obviously sensible and logical as one would hope. In a CA cert common name, what would "2025" mean? Generated that year? Expiring that year? What if we end up doing two ceremonies in the same year? Are intermediates generated a few years later named after the current year, or do they share the same name as the root they're issued from?
All naming schemes require people to be familiar with the scheme.
2 Likes
While I can't disagree with this, and I won't, IMO almost everything is better than X -> Y -> Z -> A (?) -> B (?) et cetera.
But there's no need to re-iterate that discussion.
Point is, there's no real hard need to strictly only use one or two characters if we're sending huge RSA chains with cross-signed roots for the time being, until Google decides the web needs to dance to one of their other tunes.
1 Like