Hi Ben and Kathleen,
“Insofar as the S/MIME or TLS Baseline Requirements attempt to define their own scope, the scope of this policy (section 1.1) overrides that. CA operations relating to issuance of all S/MIME or TLS server certificates in the scope of this policy SHALL conform to the S/MIME or TLS Baseline Requirements, as applicable.” Section 1.1 of the MRSP states “[…], such end entity certificates having either: an Extended Key Usage (EKU) extension that contains one or more of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection; or [….]” Section 1.1 of the SBR states “An S/MIME Certificate for the purposes of this document can be identified by the existence of an Extended Key Usage (EKU) for id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4) and the inclusion of a rfc822Name or an otherName of type id-on-SmtpUTF8Mailbox in the subjectAltName extension.” Is the intention of the Mozilla Root Store Policy update to apply the SMIME BRs to all certificates with the EKU EmailProtection, including certificates without an rfc822Name or an otherName, such as certificates for document and pdf signing purposes? I recall these use cases being discussed in the working group and intentionally out-scoping them from the SBRs to avoid unintended adverse effects, so wonder how to interpret the proposed update to the MRSP. Kind regards, Christophe From: dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> On Behalf Of Ben Wilson Sent: Wednesday, June 14, 2023 12:54 AM To: dev-secur...@mozilla.org <dev-security-policy@mozilla.org> Subject: MRSP 2.9: S/MIME BRs and Audits All, This email opens up discussion of our proposed resolution of GitHub Issue #258 <https://github.com/mozilla/pkipolicy/issues/258> (SMIME Baseline Requirements). We plan to add requirements to version 2.9 of the <https://www.mozilla.org/projects/security/certs/policy/> Mozilla Root Store Policy regarding the CA/Browser Forum’s S/MIME Baseline Requirements. We propose to update Mozilla’s Root Store Policy to require annual S/MIME BR audits as follows. * Section 2.2, second bullet point modified to directly reference that email verification must be in accordance with section 3.2.2 of the S/MIME BRs * Section 2.3, * First paragraph – add the following sentence (as a second sentence): Certificates issued on or after September 1, 2023, that are capable of being used to digitally sign or encrypt email messages, and CA operations relating to the issuance of such certificates, MUST conform to the latest version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates. o Change the remaining references of “Baseline Requirements” in this section to “S/MIME and TLS Baseline Requirements”. To indicate that the statements apply to both. * Section 3.1.2 * Add ETSI TS 119 411-6 as audit criteria * Add WebTrust for CAs - S/MIME as audit criteria * Sections 3.2, 3.3, 5.2, 7.1 * Change “Baseline Requirements” to “S/MIME and TLS Baseline Requirements”. To indicate that the statements apply to both. * Section 5.1 add a statement: “The following curves are not prohibited, but are not currently supported: P-521, Curve25519, and Curve448.” * And add a sentence: “EdDSA keys MAY be included in certificates that chain to a root certificate in our root program if the certificate contains ‘id-kp-emailProtection` in the EKU extension. Otherwise, EdDSA keys MUST NOT be included.” * Section 5.3.1 * Move the following sentence from the end of the current second paragraph up to its own stand-alone paragraph. * "The conformance requirements defined in section 2.3 of this policy also apply to technically constrained intermediate certificates." * Revise last paragraph with proposed new text: * “If the intermediate CA certificate includes the id-kp-emailProtection extended key usage, then to be considered technically constrained, it MUST comply with section 7.1.5 of the <https://cabforum.org/smime-br/> S/MIME Baseline Requirements and include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees, each such name having its ownership validated according to section 3.2.2 of the <https://cabforum.org/smime-br/> S/MIME Baseline Requirements.” * Change remaining existing occurrences of “Baseline Requirements” to “TLS Baseline Requirements”. We look forward to your constructive feedback on these proposed changes to the MRSP. We will start a separate discussion about dates/timelines and when compliance audits will be due for these new requirements. Regards, Ben and Kathleen -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org <mailto:dev-security-policy+unsubscr...@mozilla.org> . To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaHxfSrm7m_2MNXh7wZ-66Cgj_cmn-OMqJv2KH1xiad4w%40mail.gmail.com <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaHxfSrm7m_2MNXh7wZ-66Cgj_cmn-OMqJv2KH1xiad4w%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PSAPR03MB5717487AE19BB6FEC62947CEE52CA%40PSAPR03MB5717.apcprd03.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
