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 <bwil...@mozilla.com> 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 < > 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%2B1gtabgYj857DYor1hXEMSicOGrAw1fbb6SVj8unfUkAEfiHg%40mail.gmail.com.
