Preview of our upcoming Root Ceremony

[aarongable]

Trying to put everything in one big reply, hope I don't miss anything...

@jvanasco

"Ye" is the current legal name of a celebrity formerly known as "Kanye West".

I'm aware, and trust me, I don't like it either. But every set of just two letters will run into this problem eventually. If we jump to the beginning of the alphabet, "AR" is the common name of a mass murder weapon. I think it's more important that we simply pick a scheme which makes sense, and stick with it. Everyone who is serious will understand; anyone who truly believes the name is a reference or an endorsement is unserious.

@9peppe

Keeping the numbers might be a better idea.

We already have precedent for indicating algorithm with a single "E" or "R", as do many other CAs. And as we expand into more algorithms in a post-quantum world, numbers will be confusing and hard to interpret. Fundamentally: numbers should be used for things in a sequence, and different algorithms are not sequenced. The name "ISRG Root X2" was, in hindsight, arguably a mistake.

@ghen

How about Root 25E and Root 25R?

While I like this idea, it makes it harder to clearly indicate which intermediates are of the same "generation" as their issuing roots. When we issue another batch of intermediates in 2028, would those be "25E4" or "28E4"? (And imo having two different numbers in there is also confusing.)

@ghen

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

Yes. This is an unavoidable consequence of the fact that ISRG Root X1 and ISRG Root X2 will be removed from the Chrome trust store as soon as the last cert issued from the old hierarchy expires. Any website which serves a chain which includes only Root YR will be untrusted by old clients; any website which serves a chain which includes only ISRG Root X1 will be untrusted by new clients. We must provide a chain that includes both of those roots for compatibility with both updated and un-updated chrome instances.

@bruncsak

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.

Yes, unfortunately. See the above for why cross-signing the intermediates themselves will prove insufficient, since updated Chrome trust stores will not trust those chains. We will offer shorter and longer alternate chains, but the default chains will include signatures from both generations of roots.

@MaxHearnden

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?

This is a good question, and I think you're right to point out that the current language seems overly restrictive. However, it is definitively acceptable to issue Root and Subordinate CA certificates with these values in their Common Name field, as documented in Section 7.1.2.10.2 of the Baseline Requirements, "CA Certificate Naming".

@petercooperjr

Is there a shortage of numbers I'm unaware of?

There's a shortage of mental space, both amongst subscribers and amongst CA operators (i.e. me). I don't want to have to remember whether "R36" was generated in the most recent ceremony, or the one before that, or actually hasn't been generated yet...

@petercooperjr

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.

Memorable and meaningful are very different things. "Kai" is a memorable name, but provides zero indication of algorithm or generation date.

@petercooperjr

I would like to hear the reasoning for continuing to use P-384 for intermediates instead of P-256.

Because it's too late to make a difference. I understand the urge to use P-256, to support the tiny subset of clients that only implement a subset of ECDSA validation algorithms. However, I think the population of clients which can't validate P-384 but do have trust stores recent enough to include ISRG Root X2 is vanishingly small, if it exists at all (given that ISRG Root X2 is P-384 itself). So imagine a scenario where Root YE and YE1 are both P-256. A system which can't validate P-384 is still going to fail to trust an ECDSA certificate: they'll validate the signature from YE1, then validate the signature from Root YE, and then... fail to validate the cross-sign from ISRG Root X2. So changing algorithms to support that subset of clients will be ineffective.

The P-384 keys and sigs are so much smaller than RSA 2048 and 4096 that the full EE <- YE1 <- Root YE <- ISRG Root X2 <- ISRG Root X1 chain is still smaller than the shorter EE <- YR1 <- Root YR <- ISRG Root X1 chain.

@petercooperjr

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.

Yep. We still plan to switch to E7/E8/R12/R13 later this year. But thanks to the rotations we've already done, and the rotation we'll be doing this year, we no longer feel the urgency to continue rotating intermediates every year like clockwork. So this time around we plan to issue 3 intermediates of each type, rotate randomly between two of them, hold the third as backup, and simply conduct another intermediate ceremony in about two years' time.

[jvanasco]

@aarongable

I'm aware...

Great! My wife works in brand management; I once worked for a branding company and work in Product Management -- so stuff like this pops out to me. I just wanted to ensure ISRG took that into consideration, and it is clear that you all have!

[webprofusion]

As an aside, is there a current industry initiative anyone knows about to work on getting trust stores (not just google chrome) updated in a more orderly fashion?

We've seen with ISRG Root X1 that while the majority of trust stores currently do get updated, millions of them don't (on servers and clients), and I wondered if we're in a better position now or if there is more work needed there.

I'm wondering if we need a opinionated tool to check and update (or suggest updates for) trust stores even on legacy systems, outside of traditional OS/app update infrastructure, or even if such a thing already exists. [Edit: LGTM lol]

[Nummer378]

This has been a huge problem for many years, as each vendor just does whatever. I think the major problem is that having a static, non-updateable trust store used to just work. Roots were not that old, but valid for 30 years or so, new CAs were not frequent enough. So you could get away with being lazy.

This has changed, and platforms which can't properly update their trust stores will run into more and more problems. I hope that this causes enough pain for the vendors to fix it.

Google for instance has finally fixed their trust store with Android 14, making it updateble without requiring an OS upgrade. The browsers are already used to pushing updates like this for quite some time now. Oracle still does whatever I believe, and I've no idea about the situation on the Apple front.

All other smaller vendors, like IoT and such, have always been doing the minimal solution and will probably continue to do so.

[petercooperjr]

@aarongable

@petercooperjr

I would like to hear the reasoning for continuing to use P-384 for intermediates instead of P-256.

Because it's too late to make a difference. I understand the urge to use P-256, to support the tiny subset of clients that only implement a subset of ECDSA validation algorithms.

So you have a good argument for not switching to P-256 for systems that only handle that ECDSA curve. But what about how P-256 seems to be much more performant and studied? I don't know much about it myself beyond @Nummer378's posts. I don't really object to using more bits for keys & signatures, just trying to understand the decision-making process around it. (If for nothing else, to try to understand which one to use for systems myself.)

[Nummer378]

My posts are, of course, my opinions and Let's Encrypt can obviously disagree or value them differently. I think the ship has sailed for them now. I remember LE asking about feedback for a particular curve when ECDSA chains were new, but now they've decided on P-384.

You can still select whatever curve you want (well, your options are limited) for the EE cert. The performance of P-256 can be significantly better than P-384, but the relevance of this is depends on your perspective. For clients it usually doesn't matter much, network latency is significantly higher than any computation in the handshake. Actually, if you want the fastest possible signature validation, RSA-2048 should be faster than anything else (depends on your machine of course). The most savings are serverside: Your TLS server signatures and Let's Encrypts HSM performance. The server signature doesn't depend on Let's Encrypts choice. So the only remaining aspect is if Let's Encrypt wants to save a few Watts on their side.

[MaxHearnden]

How will /tmp/ceremony-tools be created or will another tools directory be used instead?

[ghen]

@aarongable

But every set of just two letters will run into this problem eventually.

How about using some separator, like "Root Y/E" and "Root A/R", to avoid potential interpretation as words?
It also makes it clearer that the two letters stand for two different things (generation vs. algorithm).

I'd still prefer number+letter combinations for that reason though.

[aarongable]

@MaxHearnden

How will /tmp/ceremony-tools be created or will another tools directory be used instead?

The run.sh script in the ceremony-demos repo is just that: a demo. We do not use this exact script for the ceremony: this one is designed to run on a variety of dev environments, while the real one is very specifically designed to run on the dedicated ceremony host. We don't even use these exact configs, since these have HSM slot and pin configurations which reference the demo repo's checked-in softhsm2 state, rather than the actual slots on our hardware HSMs.

The real scripts and real configs are produced via mechanical transformation of the contents of this demo repo, reviewed and approved by our policy management authority and security officers, and locked. The ceremony itself is then carefully documented, recorded, and observed by auditors.

All of that is to say, the path /tmp/ceremony-tools directory is not part of the real ceremony.