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 < christophe.bonj...@globalsign.com> 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:* 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 Mozilla Root Store > Policy <https://www.mozilla.org/projects/security/certs/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 S/MIME > Baseline Requirements <https://cabforum.org/smime-br/> 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 > S/MIME > Baseline Requirements <https://cabforum.org/smime-br/>.” > > > - 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. > 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/CA%2B1gtaYxZ_CrrJKow_-47BYRh3zrAE1cuJnL7%2Bgqn%2B9F9gkCMQ%40mail.gmail.com.
