On Tuesday, December 15, 2020 at 2:41:10 PM UTC-6, Ben Wilson wrote: > All, > > This email is part of the discussion for the next version of the Mozilla > Root Store Policy (MSRP), version 2.7.1, to be published during of Q1-2021. > > For audit delays, we currently require that audit statements disclose the > locations that were and were not audited, but that requirement has not been > incorporated yet into the MRSP. See > https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations. That > provision reads as follows: > > Disclose each location (at the state/province level) that was included in > the scope of the audit or should have been included in the scope of the > audit, whether the inspection was physically carried out in person at each > location, and which audit criteria were checked (or not checked) at each > location. > > - If the CA has more than one location in the same state/province, then > use terminology to clarify the number of facilities in that state/province > and whether or not all of them were audited. For example: "Facility 1 in > Province", "Facility 2 in Province, Facility 3 in Province" *or* > "Primary Facility in Province", "Secondary Facility in Province", "Tertiary > Facility in Province". > - The public audit statement does not need to identify the type of > Facility. > - "Facility" includes: data center locations, registration authority > locations, where IT and business process controls of CA operations are > performed, facility hosting an active HSM with CA private keys, > facility or > bank deposit box storing a deactivated and encrypted copy of a > private key. > > It is proposed by Issue #207 > <https://github.com/mozilla/pkipolicy/issues/207> that this language > requiring the disclosure of site locations--audited and unaudited--be made > clearly part of the MSRP by reference to the language above. > > A similar method of incorporating by reference has been taken in section > 2.4 of the MSRP > <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents> > > with respect to incident reporting and in section 7.1 > <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#71-inclusions> > > with requirements for the CA inclusion process. > > It is proposed that we add a new subsection 10 to MRSP section 3.1.4 > <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#314-public-audit-information> > > that would require that audit documentation disclose the facility site > locations that were, or were not, examined. > > One concern that has been raised previously is that the Baseline > Requirements do not define "facility site location". However, we believe > that the language above at > https://wiki.mozilla.org/CA/Audit_Statements#Minimum_Expectations > accomplishes that. We're open to suggestions for re-wording parts of it to > make it even better. > > Currently, the audit letter template for WebTrust for CAs references the > site location audited (at the level of specificity that is proposed > above). Over this past year, due to COVID, some ETSI attestation letters > have also explained which sites were and were not checked. This approach > seems to work, and the additional information will be beneficial in the > future as we evaluate the security and trust of PKI service providers. > > So, for the page cited above, we intend to move "Minimum Expectations" out > from under "Audit Delay" so that it stands separately as a requirement for > disclosing the facility site location. Then we will also revise MRSP > section 3.1.4 by inserting a new subsection 10 to require "facility site > locations that were, or were not, examined" with a hyperlink to the Minimum > Expectations language cited above. > > We look forward to your comments and suggestions. > > Sincerely yours, > > Ben
Hi Ben. Happy New Year. I have asked the WebTrust Task Force members to provide their comments and Don and I will then provide a more detailed response. I wanted to be sure to get each of the major firms' feedback before responding. Thank you. Jeff _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
