Hi Ben
Thanks for the proposed changes to the wording – this resolves my concerns. Christophe From: Ben Wilson <[email protected]> Sent: Wednesday, July 19, 2023 11:06 PM To: Christophe Bonjean <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: MRSP 2.9: S/MIME BRs and Audits All, For comment and discussion, here is some draft language for replacement in MRSP section 1.1 Scope <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#11-scope> : ------ Begin MRSP Proposal ------ This policy applies, as appropriate, to certificates matching any of the following … 3. end entity certificates that have at least one valid, unrevoked chain up to such a CA certificate through intermediate certificates that are all in scope and * an Extended Key Usage (EKU) extension that contains the anyExtendedKeyUsage or id-kp-serverAuth KeyPurposeId, or no EKU extension (i.e. a "server certificate"); or * an EKU extension of id-kp-emailProtection and an rfc822Name or an otherName of type id-on-SmtpUTF8Mailbox in the subjectAltName (i.e. an "email certificate"). ------ End MRSP Proposal ----- This language would replace what is currently in MRSP section 1.1 <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#11-scope> : * 3. end entity certificates that have at least one valid, unrevoked chain up to such a CA certificate through intermediate certificates that are all in scope, 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 * no EKU extension. Thoughts? Ben On Wed, Jul 19, 2023 at 10:32 AM Ben Wilson <[email protected] <mailto:[email protected]> > wrote: Hi Christophe, Thanks for pointing out this issue. I will work this into my edits on Github so that the scope of the Mozilla Root Store Policy for S/MIME certificates is narrowed. In other words, I'll add the language "and the inclusion of a rfc822Name or an otherName of type id-on-SmtpUTF8Mailbox in the subjectAltName extension" to the draft of version 2.9 that I'm working on so that an S/MIME certificate, for purposes of the MRSP, must have not only the emailProtection EKU, but also an RFC822 name or an otherName of type id-on-SmtpUTF8Mailbox in the SAN. Does that resolve your concern? Thanks, Ben On Thu, Jul 6, 2023 at 9:47 AM Christophe Bonjean <[email protected] <mailto:[email protected]> > wrote: 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: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of Ben Wilson Sent: Wednesday, June 14, 2023 12:54 AM To: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > 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 "[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/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 "[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/PSAPR03MB5717EE0E05C7A372A2F80B39E500A%40PSAPR03MB5717.apcprd03.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
