MRSP 2.9: S/MIME BRs and Audits
Ben Wilson
All,
This email opens up discussion of our proposed resolution of GitHub Issue #258 (SMIME Baseline Requirements).
We plan to add requirements to version 2.9 of the 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.
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 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.”
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
Stephen Davidson
Thank you Ben and Kathleen
The current “SMC03: Corrections and clarifications” ballot for the S/MIME Baseline Requirements (SBR) includes a proposed change relevant to this topic.
Section 8.4 https://github.com/cabforum/smime/blob/SMC03/SBR.md#84-topics-covered-by-assessment will be updated as follows (adding reference to 411-2 and emphasis on “AND this document”):
3. "ETSI EN 319 411-1 v1.3.1 or newer" or "ETSI EN 319 411-2 v2.4.1 or newer", which includes normative references to ETSI EN 319 401 (the latest version of referenced ETSI documents should be applied) AND this document; or
ETSI is currently working on a new standard called ETSI TS 119 411-6 to describe how the 411-1 (General) and 411-2 (Qualified) certificate policies may be used with the SBR certificate policies, and “pulls in” the current SBR requirements as needed into the ETSI 411-1/411-2 audit.
Once ETSI TS 119 411-6 is approved, the SBR will be updated again to include that standard.
Regards, Stephen
Chair, CA/B Forum S/MIME Certificate Working Group
From: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
On Behalf Of Ben Wilson
Sent: Tuesday, June 13, 2023 7:54 PM
To: dev-secur...@mozilla.org <dev-secur...@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 (SMIME Baseline Requirements).
We plan to add requirements to version 2.9 of the 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 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 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-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
dev-security-po...@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.
Christophe Bonjean
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-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ben Wilson
Sent: Wednesday, June 14, 2023 12:54 AM
To: dev-secur...@mozilla.org <dev-secur...@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 (SMIME Baseline Requirements).
We plan to add requirements to version 2.9 of the 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 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 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
--
Ben Wilson
Ben Wilson
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:
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.
Christophe Bonjean
Hi Ben
Thanks for the proposed changes to the wording – this resolves my concerns.
Christophe
Ben Wilson
Ben Wilson
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 EKU extension that contains the anyExtendedKeyUsage KeyPurposeId, or no EKU extension;
- an EKU extension that contains the id-kp-serverAuth KeyPurposeId; or
- an EKU extension that contains the id-kp-emailProtection KeyPurposeId and an rfc822Name or an otherName of type id-on-SmtpUTF8Mailbox in the subjectAltName.