Thanks, Martijn, Jeremy, and others who have commented on Issue #279 thus far. I am thinking that I should conduct a CA survey to determine the S/MIME use cases and the reasons for ensuring the validity of multipurpose S/MIME certificates into the 2029 timeframe. I also need to take a closer look at the logistics of removing trust bits vs. adding distrust-after dates, and I'll get back to you on this. Thanks again, Ben
On Mon, Dec 23, 2024 at 3:11 AM 'Martijn Katerbarg' via [email protected] <[email protected]> wrote: > 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. > > > 2. 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. > > > 2. 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]. > 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 > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SA1PR17MB6503D26602094A482EBEC3D5E3022%40SA1PR17MB6503.namprd17.prod.outlook.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/CA%2B1gtab5e%2BAS%3D6gzhu_FOkFQAeFsOq5GsNSW9P7CS8XmJaTfOQ%40mail.gmail.com.
