Hi Sándor, Good question! The first interpretation is correct. The authorityKeyIdentifier extension is merely RECOMMENDED to be present, but *if it is* present, then the keyIdentifier field of the extension MUST be present. Section 7.1.2.1.3 should not be interpreted as saying that the keyIdentifier field MUST be present *in the certificate*. Rather, it says that the keyIdentifier field MUST be present *in the authorityKeyIdentifier extension*.
For the record, we are choosing not to include the authorityKeyIdentifier extension in our self-signed Root CA Certificates because it is wholly redundant with the subjectKeyIdentifier extension in those same certificates. It is unclear to me why this extension is even RECOMMENDED for Root CA Certificates; in my personal opinion it should be NOT RECOMMENDED. Aaron On Wed, Jul 23, 2025 at 6:02 AM Szőke Sándor <[email protected]> wrote: > Hi Aaron, > > > > thank you for sharing your plans with us. > > We are also planning to set up new hierarchies in the near future, so it's > great to see how others are planning to do this to minimize the risk of > making sg. wrong. > > > > I have reviewed your information and have only one question. > > I see that you are not planning to include the authorityKeyIdentifier > extension in your new root certificates. > > > > CABF TLS BR says: > > > > *7.1.2.1.2 Root CA Extensions* > > *Extension* > > *Presence* > > *Critical* > > *Description* > > authorityKeyIdentifier > > RECOMMENDED > > N > > See Section 7.1.2.1.3 > > > > *7.1.2.1.3 Root CA Authority Key Identifier* > > *Field* > > *Description* > > keyIdentifier > > MUST be present. MUST be identical to the subjectKeyIdentifier field. > > authorityCertIssuer > > MUST NOT be present > > authorityCertSerialNumber > > MUST NOT be present > > > > > > These requirements can be interpreted in two ways, so it may be useful to > clarify this issue. > > > > - According to the first interpretation, this extension is only > RECOMMENDED according to section 7.1.2.1.2, and section 7.1.2.1.3 only > needs to be followed if this extension is included in the root certificate. > Therefore, it is not a problem if the root certificate does not contain the > authorityKeyIdentifier extension. > - According to the other interpretation, both requirements must be met > because they are at the same hierarchical level in the BR. The second > requirement is not a sub-section of the first chapter and does not contain > a clear statement that it only needs to be complied with if this extension > is included in the root certificate. According to this logic, the > authorityKeyIdentifier MUST be included in the certificate. > > > > Which is the correct interpretation of the CABF TLS BR requirement? If it > is the second one, it would probably be useful to add some clarifying > additions to the second paragraph for greater clarity. > > > > Kind Regards, > > > > Sándor > > > > > > *From:* 'Aaron Gable' via [email protected] < > [email protected]> > *Sent:* Saturday, July 19, 2025 12:31 AM > *To:* [email protected] <[email protected]> > *Subject:* Preview of Let's Encrypt's upcoming Root Ceremony > > > > Hi MDSP! > > It's 2025, which means that ISRG Root X1 is a decade old and ISRG Root X2 > is five years old. As such, Let's Encrypt is 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 > <https://github.com/letsencrypt/ceremony-demos/tree/2025-configs/outputs/2025> > > 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 <https://letsencrypt.org/certificates/> 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 > <https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/>. > > Thanks again, > Aaron Gable > on behalf of Let's Encrypt > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErf%3DR5%2Bz8f578jV6OJnJ4PS1bYj90TGh9jca1nq0kmY1sA%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErf%3DR5%2Bz8f578jV6OJnJ4PS1bYj90TGh9jca1nq0kmY1sA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErc_5yHidAwGv24bxgpetRK%3DEtpQ9V%3Dmey39LVVTviBK%2BQ%40mail.gmail.com.
