Ben, As Jeremy also pointed out, the proposed deadline seems too strict for S/MIME purposes.
I’m assuming this will be done the same way as with the root deprecation based on key creation date, in that Mozilla will disable trust bits for roots on or after January 1, 2027. If so, S/MIME is already in trouble. Even for the Multipurpose and Strict profiles, which allow issuance for 2 years (825 days). Any certificate issued based on those profiles today for the maximum term, would expire in 2027, i.e. past the stated deadline. Regards, Martijn Katerbarg Sectigo From: [email protected] <[email protected]> on behalf of Jeremy Rowley <[email protected]> Date: Friday, 20 December 2024 at 17:13 To: [email protected] <[email protected]> Subject: Re: MRSP 3.0: Issue #279: TLS-specific and S/MIME-specific Root CAs One additional thought I had on this is that it moves SMIME to strict profiles faster than previously intended. From the SMIME BRs: Strict: id-kp-emailProtection SHALL be present. Other values SHALL NOT be present. Multipurpose and Legacy: id-kp-emailProtection One additional thought I had on this is that it moves SMIME to strict profiles faster than previously intended. >From the SMIME BRs: Strict: id-kp-emailProtection SHALL be present. Other values SHALL NOT be present. Multipurpose and Legacy: id-kp-emailProtection SHALL be present. Other values MAY be present. The values id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, and anyExtendedKeyUsage SHALL NOT be present. Moving to strict instead of multi-purpose is fine IMO, except we should do a survey to find out what will break. IIRC, there were a few Microsoft products that required Microsoft EKUs to work properly. I'd put the burden on the CAs to provide information about what will break with moving to strict instead of multi-purpose full chain certificates, but I would like to know what will break by restricting SMIME more than the CABF does. On Thursday, December 19, 2024 at 11:19:44 AM UTC-7 Jeremy Rowley wrote: The extensions look right to me. I think that's a short timeline for email certificates considering the legacy profile is still allowed. Do you want to split it into two? A timeline for TLS compared to email? On Thu, Dec 19, 2024 at 6:12 AM Mike Shaver <[email protected]> wrote: I can’t speak to the extension-value details, but I agree with it being a good change. Mike On Thu, Dec 19, 2024 at 12:17 AM 'Ben Wilson' via [email protected] <[email protected]> wrote: All, Here for comment is a first draft of a proposal to phase-out multi-purpose root CA certificates. This is tied to GitHub Issue #279<https://urldefense.com/v3/__https:/github.com/mozilla/pkipolicy/issues/279__;!!J5K_pWsD!1Pdh6wrUwVs1p_vQImAzmKTvk4z0U40gmrfAgYmGph9pnBDs-fdFKfOyAYMNQPuEr7pmQF1G5dPM6o1vlIiEa_ry$>, referenced in the subject line above. This proposal is that a new Section 7.5 be added to the Mozilla Root Store Policy (MRSP). Other conforming changes would be made elsewhere in the MRSP to remove any implication that a root CA certificate could have both the websites trust bit and the email-protection trust bit after January 1, 2027. Please provide any comments or suggestions you might have to improve or change this proposal. Thanks, Ben 7.5 Dedicated Root Certificates Effective immediately, all root CA certificates being considered for inclusion in Mozilla's Root Store MUST be dedicated either to TLS server authentication or to S/MIME email protection. Existing root CA certificates that do not comply with this requirement MUST be replaced or transition to a dedicated hierarchy prior to January 1, 2027. 7.5.1 TLS Server Authentication Roots Root CA certificates dedicated to TLS server authentication with the websites trust bit enabled MUST meet the following criteria: 1. All subordinate CA certificates MUST: * Include the extendedKeyUsage extension and assert only: * id-kp-serverAuth; or * Both id-kp-serverAuth and id-kp-clientAuth. * Not share a public key with any certificate that asserts a different extendedKeyUsage value. 1. All end-entity certificates issued MUST: * Include the extendedKeyUsage extension and assert only: * id-kp-serverAuth; or * Both id-kp-serverAuth and id-kp-clientAuth. 7.5.2 S/MIME Roots Root CA certificates dedicated to S/MIME with the email protection trust bit enabled MUST meet the following criteria: 1. All subordinate CA certificates MUST: * Include the extendedKeyUsage extension and assert only: * id-kp-emailProtection; or * Both id-kp-emailProtection and id-kp-clientAuth. * Not share a public key with any certificate that asserts a different extendedKeyUsage value. 1. All end-entity certificates issued MUST: * Include the extendedKeyUsage extension and assert only: * id-kp-emailProtection; or * Both id-kp-emailProtection and id-kp-clientAuth. 7.5.3 Transition Plan for Existing Multi-Purpose Roots Root CA certificates included in Mozilla's Root Store as of January 1, 2025, with both the websites and the email trust bits enabled, MAY continue to be trusted after January 1, 2026, if by such date the CA operator has submitted a transition plan that demonstrates a feasible migration to a dedicated hierarchy that will be completed prior to January 1, 2027. Transition plans MUST address the following: 1. Existing submissions of requests for inclusion of new single-purpose roots; 2. Requests to remove the websites trust bit or the email trust bit from a multi-purpose root; and 3. Timelines for phasing out multiple uses of the root--dates by which certificates that do not meet the requirements of Sections 7.5.1 or 7.5.2 will be revoked, expire, be replaced, or for which issuance will cease. -- 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/CA%2B1gtaYWFREw%2B0KOU61bVgjZXxHZuvQyXmQDSbMgMZqVk18FTQ%40mail.gmail.com<https://urldefense.com/v3/__https:/groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA*2B1gtaYWFREw*2B0KOU61bVgjZXxHZuvQyXmQDSbMgMZqVk18FTQ*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUl!!J5K_pWsD!1Pdh6wrUwVs1p_vQImAzmKTvk4z0U40gmrfAgYmGph9pnBDs-fdFKfOyAYMNQPuEr7pmQF1G5dPM6o1vlNAu95UW$>. -- 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/CADQzZqt_NZxJQ8L8ZX7UxDqKPsHTvNMSZTmedJoJ6r3g98kvhQ%40mail.gmail.com<https://urldefense.com/v3/__https:/groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqt_NZxJQ8L8ZX7UxDqKPsHTvNMSZTmedJoJ6r3g98kvhQ*40mail.gmail.com?utm_medium=email&utm_source=footer__;JQ!!J5K_pWsD!1Pdh6wrUwVs1p_vQImAzmKTvk4z0U40gmrfAgYmGph9pnBDs-fdFKfOyAYMNQPuEr7pmQF1G5dPM6o1vlL83ozSc$>. -- 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]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/83193857-0c75-4935-8002-1b846d560552n%40mozilla.org<https://urldefense.com/v3/__https:/groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/83193857-0c75-4935-8002-1b846d560552n*40mozilla.org?utm_medium=email&utm_source=footer__;JQ!!J5K_pWsD!1Pdh6wrUwVs1p_vQImAzmKTvk4z0U40gmrfAgYmGph9pnBDs-fdFKfOyAYMNQPuEr7pmQF1G5dPM6o1vlDzq4b4J$>. -- 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/SA1PR17MB6503D26602094A482EBEC3D5E3022%40SA1PR17MB6503.namprd17.prod.outlook.com.
