All, This August 2023 CA Communication and Survey was sent out to CAs already in our program last Tuesday (August 22) and to CAs applying for inclusion yesterday (August 28). The deadline for responses is September 15. If any CA in our program or applying to our program did not receive the CA Communication and Survey, then please contact me directly, and I will provide you with the link. Thanks, Ben
On Fri, Aug 18, 2023 at 4:20 PM Ben Wilson <bwil...@mozilla.com> wrote: > All, > Below for your review and comment is a draft CA Communication and Survey > to be sent next week via the CCADB to all CA operators in Mozilla's root > store. > Thanks, > Ben > Mozilla CA Operator Survey - Respond By September 15, 2023Section 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 > certifica...@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..f82afed8a7df2598824804e84b6961f89b3969cd> > 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 > <https://docs.google.com/document/d/1ieXSt3rJyOSopJnDp4wFGSugpk6pt5pJFJ55rkpb6Ks/edit?usp=sharing> > > 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 <https://cabforum.org/smime-br/> (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 <https://cabforum.org/smime-br/>, > Mozilla’s new S/MIME requirements, and Mozilla's transition guidance > <https://wiki.mozilla.org/CA/Transition_SMIME_BRs>, 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 > <https://wiki.mozilla.org/CA/Transition_SMIME_BRs>. (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 > <https://wiki.mozilla.org/CA/Vulnerability_Disclosure>, 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 <https://www.ccadb.org/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 > - > > the audit team’s qualifications (see > <https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications> > - > > 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. > -- 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%2B1gtaZWVhrVJ3JqfPYDuMy%2BHZNSU9C45K7CYzz6XzWEUYmUww%40mail.gmail.com.
