MRSP 2.9: Draft CA Communication and Survey
Ben Wilson
Mozilla CA Operator Survey - Respond By September 15, 2023
Section 1:
The purpose of this communication and survey is to ensure that CA operators are aware of and prepared to comply with recent changes to the Mozilla Root Store Policy (MRSP), v. 2.9, effective September 1, 2023.[1]
CAs are expected to comply, without exception, with the MRSP, and to ensure ongoing compliance, CAs should carefully review this policy and the changes in MRSP v.2.9 from version 2.8.1.[2] These changes have been discussed on the Mozilla dev-security-policy list.[3] CAs that did not participate in such discussions or that have not yet reviewed those conversations should also read them to reduce the chance of confusion or misinterpretation.
In accordance with MRSP § 4.2[4], CA operators will be required to respond to the questions on this form[5] on or before September 15, 2023. The questions included in the survey are also available here [6].
Results will be reviewed by Mozilla and may be shared publicly to inform us regarding these and future changes to the MRSP.
For questions, concerns, or issues related to this survey, please email certif...@mozilla.org.
Thanks,
Ben and Kathleen
Mozilla CA Program
References:
[1] https://github.com/BenWilson-Mozilla/pkipolicy/blob/2.9/rootstore/policy.md
[2] https://github.com/mozilla/pkipolicy/compare/e8a3f55ea7565bc72e9f9e9ab3e57c993fb0812d..117054ecf1eff757cfebe40d7c952ce1e3fca920
[3] https://groups.google.com/a/mozilla.org/g/dev-security-policy/search?q=%22mrsp%202.9%22
[4] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#42-surveys
[5] Redacted
[6] Redacted
Section 2: CA Operator Information
What is your name? _________________________________
What is your email address? (i.e., how can we get in touch with you if we have questions related to a specific answer in your response?) _________________________________
What is your organization's "CA Owner" name as listed in CCADB? (i.e., this is the organization you are authorized to represent in CCADB). Please use the exact value as it appears in CCADB.
_________________________________
Section 3: Retirement of Older Root CA Certificates
Background:
According to MRSP § 7.4, root CA certificates enabled with the websites trust bit will have that bit removed when CA key material is 15 years old, and at 18 years from the CA key material generation date for a Root CA certificate with the email trust bit, a "Distrust for S/MIME After Date" will be set.
As of July 1, 2012, most CAs were required to obtain an auditor-witnessed key generation ceremony report. If a CA operator cannot provide a key generation ceremony report for a root CA certificate, then Mozilla will use the “Valid From” date in the root CA certificate to establish the key material generation date.
For transition purposes, root CA certificates in the Mozilla root store will be distrusted according to the schedule located at https://wiki.mozilla.org/CA/Root_CA_Lifecycles, which is subject to change if underlying algorithms become more susceptible to cryptanalytic attack or if other circumstances arise that make that schedule obsolete.
We have the following questions or concerns about MRSP § 7.4 (Root CA Lifecycles) and/or the transition schedule posted on the wiki. (Either write "None" or describe below)
_________________________________
Section 4: Compliance with the CABF’s S/MIME BRs
Background:
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’s Baseline Requirements for S/MIME certificates (S/MIME BRs).[MRSP § 2.3]
Also of note under Mozilla Policy:
For end entity certificates, the scope of the MRSP includes those with the emailProtection EKU and an rfc822Name or an otherName of type id-on-SmtpUTF8Mailbox in the subjectAltName.[MRSP § 1.1]
Name-constrained intermediate CAs with the emailProtection EKU must be reported, but do not need to be audited. Such CA certificates must have constraints on rfc822Name, with at least one name in permittedSubtrees, each name having been validated according to § 3.2.2 of the S/MIME BRs.[MRSP § 5.3.1]
Validation of email addresses must follow § 3.2.2 of the S/MIME BRs.[MRSP § 2.2]
Period-of-time audits are required for audit periods ending after October 30, 2023.[MRSP §§ 3.1.2.1 and 3.1.2.2]
Transition guidance is provided at the following wiki page: https://wiki.mozilla.org/CA/Transition_SMIME_BRs
We have reviewed the S/MIME BRs, Mozilla’s new S/MIME requirements, and Mozilla's transition guidance, and we plan to have our first S/MIME audit by the following date. (Write the Month and Year when you plan to have the audit completed. Write "N/A" if your CAs are NOT enabled with the email trust bit.)
_________________________________
We have the following questions or concerns about Mozilla’s new S/MIME requirements, and Mozilla's transition guidance. (Write "N/A" if your CAs are NOT enabled with the email trust bit or write "None" if you have no comments. Otherwise, describe below.)
_________________________________
Section 5: Security Vulnerability Reporting
Background:
MRSP § 2.4.1 states that additionally, and not in lieu of the requirement to publicly report incidents as outlined in MRSP § 2.4, a CA Operator MUST file a secure bug in Bugzilla to disclose a serious vulnerability or security incident.
Guidance is found at the following wiki page: https://wiki.mozilla.org/CA/Vulnerability_Disclosure
We have read the Vulnerability Disclosure guidance, and in the event of a serious vulnerability or security incident, as described therein:
◯ We already have processes in place to notify Mozilla.
◯ We are putting processes in place to notify Mozilla.
◯ We have questions or concerns about Mozilla’s expectations (describe below).
Please describe your questions or concerns about this security incident and vulnerability disclosure requirement.
(Either write "None" or describe below)
_________________________________
Section 6: Audits
Background:
MRSP § 3.1.4 has been restructured to reference similar requirements found in section 5.1 of the CCADB Policy. Note that in addition to the information required by CCADB Policy § 5.1, MRSP requires that the following information also be provided with each the audit statement:
the CA locations that were or were not audited (see https://wiki.mozilla.org/CA/Audit_Statements#Audited_Locations);
the name of the lead auditor; and
https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications).
◯ Our audit reporting already meets all of these requirements.
◯ Our audit reporting will meet these requirements with the submission of our next audit report.
◯ We have questions or concerns about these audit reporting requirements (describe below).
Please describe your questions or concerns about these audit reporting requirements.
(Either write "None" or describe below)
_________________________________
Section 7: Annual Submission of CCADB Compliance Self-Assessment
Background:
Under MRSP § 3.4, CA operators with roots enabled with the websites trust bit must perform the CCADB Compliance Self-Assessment (https://www.ccadb.org/cas/self-assessment) annually and submit it within 92 calendar days from the previous “BR Audit Period End Date” that is after December 31, 2023.
CA operators should submit the self-assessment at the same time as when they provide their annual audit reports in the CCADB. CAs should use the most recent version of the Compliance Self-Assessment template (and not one that has been superseded by more than 90 calendar days before submission).
We have read the new MRSP § 3.4 (regarding the annual submission of Compliance Self-Assessments), and
◯ We will provide our Compliance Self-Assessment when it comes time to submit our annual audit report.
◯ We will have problems meeting this requirement because of the reasons described below.
◯ We have questions or concerns about this requirement (describe below).
◯ This requirement is not currently applicable because all our CAs are enabled only with the email trust bit.
Please describe your questions or concerns about the compliance self-assessment submission requirements.
(Write "N/A" if your CAs are NOT enabled with the websites trust bit or write "None" if you have no comments. Otherwise, describe below.)
_________________________________
Section 8: Elimination of SHA-1
Background:
As detailed in MRSP § 5.1.3, SHA-1 can only be used to sign: (1) end entity certificates only if they are completely outside the scope of the MRSP, or (2) a duplicate of an existing SHA-1 intermediate certificate, in specified, very-limited circumstances. SHA-1 cannot be used for signing OCSP responses, CRLs, or any other data.
We have read MRSP § 5.1.3 (regarding SHA-1), and
◯ We do not use SHA-1 to sign anything under our roots that are in Mozilla's program.
◯ We still use SHA-1 to sign out-of-scope end entity certificates under a root in Mozilla's program.
◯ We have questions or concerns about this requirement (describe below).
Please describe your questions or concerns about the elimination of SHA-1.
(Either write "None" or describe below)
_________________________________
Section 9: Review Version 2.9 of the MRSP
We have read version 2.9 of Mozilla’s Root Store Policy.
◯ Yes
◯ No
We understand and intend to comply with version 2.9 of Mozilla’s Root Store Policy.
◯ Yes
◯ No
We have the following additional questions or concerns with version 2.9 of Mozilla’s Root Store Policy (describe below or write "None").
_________________________________
Section 10: Other Questions or Comments
Please provide any other questions or comments that you would like to communicate to us.
_________________________________
Click on the Submit button to complete this survey.