Thanks, Martijn I'll change that. Ben On Fri, Jan 10, 2025 at 1:01 PM 'Martijn Katerbarg' via [email protected] <[email protected]> wrote:
> Ben, > > > They MUST NOT share a public key with any certificate that asserts any > other extendedKeyUsage values. > > In the updated proposal, to me this reads as "If CA Owner A issues an > S/MIME leaf certificate with public key A as the subject's public key, then > CA Owner B is not allowed to issue a TLS certificate with the same public > key as subject.". I assume that's not the actual intent here, and this > restiction on public keys and associated EKUs should rather be scoped to > Root CA and Subordinate CA Certificates, not leaf certificates? > > Regards, > > Martijn > > Op vrijdag 10 januari 2025 om 19:03:51 UTC+1 schreef Ben Wilson: > >> For your consideration and comment, here is another iteration. I've >> changed the transition dates and the allowed EKUs for the S/MIME >> hierarchy. >> (Also, note that per >> https://wiki.mozilla.org/CA/Root_CA_Lifecycles#Transition_Schedule, any >> root created before 2012 will have its websites trust bit removed prior to >> April 15, 2028, in any event.) >> >> *7.5 Dedicated Root Certificates* >> >> All root CA certificates added to Mozilla's Root Store after January 1, >> 2025, will only be trusted for either TLS server authentication (websites >> trust bit) or S/MIME email protection (email trust bit). Existing root CA >> certificates that do not comply with this requirement MUST transition to >> one or the other prior to December 31, 2028, i.e., by having one of their >> trust bits (websites or email) removed. >> >> *7.5.1 TLS Server Authentication Roots* >> >> Subordinate CA and end entity certificates issued under a Root CA >> certificate added after January 1, 2025, with the websites trust bit >> enabled, MUST include an extendedKeyUsage extension that asserts only >> id-kp-serverAuth or both id-kp-serverAuth and id-kp-clientAuth. They MUST >> NOT share a public key with any certificate that asserts any other >> extendedKeyUsage values. >> >> *7.5.2 S/MIME Roots* >> >> Subordinate CA and end entity certificates issued under a Root CA >> certificate added after January 1, 2025, with the email trust bit enabled >> MUST include an extendedKeyUsage extension that asserts >> id-kp-emailProtection. They MAY include other extendedKeyUsages, but >> they MUST NOT include extendedKeyUsages of id-kp-serverAuth, >> id-kp-codeSigning, id-kp-timeStamping, or anyExtendedKeyUsage. They MUST >> NOT share a public key with any certificate that asserts any other >> extendedKeyUsage values. >> >> *7.5.3 Transition Plan for Existing Roots* >> >> Root CA certificates included in Mozilla's Root Store as of January 1, >> 2025, that have both the websites and the email trust bits enabled MAY >> remain trusted after April 15, 2026, if the CA operator has submitted a >> transition plan by April 15, 2026, to migrate to dedicated hierarchies by >> December 31, 2028. >> >> Transition plans MAY include: >> >> 1. Submission of requests for inclusion of single-purpose roots; >> 2. Requests to remove the websites trust bit or the email trust bit >> from a dual-purpose root; >> 3. Timelines for phasing out conflicting uses of the root (e.g. dates >> by which inconsistent certificates will expire or issuance will cease); >> and >> 4. Revocation or re-issuance of certificates that do not meet the >> requirements of Sections 7.5.1 or 7.5.2. >> >> >> >> On Fri, Dec 27, 2024 at 4:49 PM Ben Wilson <[email protected]> wrote: >> >>> 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/cefa00db-a7cd-4ea9-83b0-006c01ec5e3dn%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/cefa00db-a7cd-4ea9-83b0-006c01ec5e3dn%40mozilla.org?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%2B1gtaYOVT2j3j-%3DyD5%2B5_-naH5%3DAE9TqTyevEOuXrcMphBviw%40mail.gmail.com.
