Maybe not but it is handy. Older RHEL CA stores use the CN as the comment line before the cert like
# ISRG Root X1
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoT
My Ubuntu 22 CA store use it as the file name
Hongkong_Post_Root_CA_3.pem
ISRG_Root_X1.pem
ISRG_Root_X2.pem
IdenTrust_Commercial_Root_CA_1.pem
It's mandated by the BRs: https://github.com/cabforum/servercert/blob/main/docs/BR.md#712102-ca-certificate-naming
Thanks; I was guessing it might be but was too lazy to look it up. And it, of course, leads to the next question of why the BRs mandate it, but that's probably getting even more off-topic than my usual rambling.
I forgot to ask before, but is any of this reserved as backup like R4 or E2 or all 5 keys will used while normal operation?
@orangepizza We do have a plan to reserve at least 1x RSA and 1x ECDSA intermediate. We'll revisit that decision again prior to allowing issuance from this generation of intermediates.
Two questions.
Edit: I understand that a compliant client will be able to handle any of these scenarios, however knowing the likely rotation/replacement patterns will allow for test suites to better model the expected real-life conditions.
The most likely deployment is:
But we're not making guarantees at this point, and this deployment strategy is one of the things we're willing to receive feedback on.
Thank's so much for that. I don't expect or need guarantees. If there is even a shortlist of 5 likely possibilities, I think those would be good to know for testing purposes.
None of this stuff should matter if there is a test that handles a single rollover successfully, but testing is cheap and running clients against real-world scenarios tends to surface some weird bug or usage pattern that just shouldn't be there.
I think it's very likely we start with 2 in use for each of RSA and ECDSA.
The "swapped in after 1 year" part is the most likely to change, as we learn from how the initial deployment goes.
It's possible we start with 3 or 4 in use immediately, holding 2 or 1 in reserve.
There's some variations on how we split issuance between the intermediates internally, but that shouldn't be visible externally.
So you're planning to incrementally use more different intermediates, to force clients (and users) to not hardcode them? Sounds like a plan to not change too many parts at once (new intermediates, new issuance stragegy). 
As other have said, all of this shouldn't matter, but there are so many broken use cases out there...
But any ACME client anywhere can/will get certificates issued from all active intermediates (of according type) ? It will not depend on geo location or anything like that?
I assume the main purpose of having different intermediates is not to disseminate the private keys to different HSMs -- I might be wildly wrong and that would require a signing ceremony every time you acquire a new HSM, but yeah, it might make sense.
We considered having some intermediates only in a single DC, but while that works for issuance, we need to serve revocation (via OCSP and CRLs) from all DCs, so we need the intermediates online at all locations.
But externally, our CDN splits traffic randomly between DCs so it’s not geo-based or anything even if we do issue one intermediate from a single DC.
Hm, question about that.. How does one distribute private keys among different locations? 
(I assume private keys are only in transit inside an offline HSM with several tamper-evident seals? If not actual humans?)
Sounds plausible, I'm curious how such a thing is actually done 
There must be a chain of custody that is maintained secure at all times.
for Luna HSM (which LE uses) this document applies:
https://thalesdocs.com/gphsm/luna/7/docs/network/Content/admin_partition/key_cloning/key_cloning.htm
How exactly it works differs per-vendor, but there’s always some way to create some sort of group of HSMs that can talk to each other and securely share key material.
Actually, new question here:
Should we expect there are no alternate chains in the forthcoming model?