Hi Phil, I am wondering about the rationale for switching the hash algorithm used for generating SKIs. If the full SHA-256 hash of the subjectPublicKey is used as the SKI value, then the intermediate certificate and end-entity certificate will each be 12 octets larger (256-bit SHA-256 hash vs. 160-bit SHA-1 hash).
If the rationale is to move away from all use of SHA-1 (even in non-security relevant contexts), then I’d recommend looking at section 2 of RFC 7093 [1]. One of the methods the RFC prescribes is using the 160 leftmost bits of the SHA-256 hash of the subjectPublicKey as the SKI value. This allows the CA to replace the use of SHA-1 with SHA-256 without incurring any certificate size increase. Namely, chains will be 24 octets smaller than they would be if the full SHA-256 hash were used. Thanks, Corey [1] https://datatracker.ietf.org/doc/html/rfc7093#section-2 From: 'Phil Porada' via [email protected] <[email protected]> Sent: Monday, December 4, 2023 2:21 PM To: [email protected] Subject: Let's Encrypt New Intermediate Certificates All, In 2024 Q1, Let's Encrypt plans to issue new intermediate keys and certificates. The exact date and time is to be determined. Most ACME clients <https://letsencrypt.org/docs/client-options/> will automatically configure new intermediate certificates, so no subscriber action should be needed. Motivation Previously in 2020 <https://letsencrypt.org/2020/09/17/new-root-and-intermediates> , Let’s Encrypt issued six new certificates: one root (ISRG Root X2), four intermediates, and one cross-sign. Those new certificates were part of our larger plan to improve privacy on the web, by making ECDSA end-entity certificates widely available, and by making overall certificate sizes smaller. The existing R3, R4, E1, and E2 intermediate certificates <https://letsencrypt.org/certificates/> are now more than halfway through their 5 year validity period, so it is time to issue new intermediates to replace them. New Keys and Certificates These new intermediates will differ from our previous batch in four ways: 1. We will be generating 5 RSA and 5 ECDSA intermediates, instead of 2 each. We plan to automatically rotate issuance between multiple intermediates for improved redundancy. 2. We will be shortening their validity period from 5 years to 3 years, to reflect our commitment to issue new intermediates every 2 years. 3. They will use SHA256 to compute their Subject Key Identifiers instead of SHA1. 4. They will only contain the Baseline Requirements Domain Validated Reserved Certificate Policy Identifier (OID 2.23.140.1.2.1 <https://cabforum.org/object-registry/> ). The five RSA intermediates will be issued from ISRG Root X1, and the five ECDSA intermediates will be issued from ISRG Root X2. In addition, the five ECDSA intermediates will be cross-signed by ISRG Root X1, to allow efficient chain-building even for clients which do not yet have ISRG Root X2 in their trust stores. In Summary We will be generating 10 new intermediate keys. * 5x 2048 bit RSA keys * 5x P-384 ECDSA keys We will be issuing 15 certificates, each with a validity period of 3 years. * 5x RSA intermediate certificates signed by ISRG Root X1 * 5x ECDSA intermediate certificates signed by ISRG Root X2 * 5x ECDSA intermediate certificates cross-signed from ISRG Root X1 A demo of this upcoming ceremony, and many of our historical ceremonies, can be found here <https://github.com/letsencrypt/ceremony-demos/> . You can view the example intermediate certificate PEM and text output here <https://github.com/letsencrypt/ceremony-demos/tree/main/outputs/2023> . Please assist us in reviewing these outputs for compliance and correctness. Let us know if you see any errors or oddities that our linting has missed. Thank you! -- You received this message because you are subscribed to the Google Groups "[email protected] <mailto:[email protected]> " group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACpGwJZOLVQUw_XsEjuMjPgbW0QbnLKu6KboZ68nLSXEY0G4zA%40mail.gmail.com <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACpGwJZOLVQUw_XsEjuMjPgbW0QbnLKu6KboZ68nLSXEY0G4zA%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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB218632616A16B3AF5450CD349286A%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
