All, Shouldn't the scope language for S/MIME certificates include the anyEKU and the absence of an EKU? In other words, shouldn't the second bullet of item 3 read, "an EKU extension of anyExtendedKeyUsage or id-kp-emailProtection, or no EKU extension, and an rfc822Name or an otherName of type id-on-SmtpUTF8Mailbox in the subjectAltName (i.e. an "email certificate")? Thanks, Ben
On Wed, Jul 19, 2023 at 3:06 PM Ben Wilson <bwil...@mozilla.com> wrote: > 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%2B1gtaacukQp6Srqam%2BX729QtMO4ECZ-rJ-a%2BxrWYp5sYT0n3A%40mail.gmail.com.
