On second thought, I think that Mozilla can accomplish what we want without modifying the MRSP <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#32-auditors> (which says audits MUST be performed by a Qualified Auditor, as defined in the Baseline Requirements section 8.2), and instead adding language to https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications that explains what additional information we need submitted to determine that an auditor is "qualified" under Section 8.2 of the Baseline Requirements.
In other words (paraphrasing from BR 8.2), we would need evidence that the persons or entities: 1. Are independent from the subject of the audit; 2. Have the ability to conduct an audit that addresses the criteria; 3. Have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function; 4. Are accredited in accordance with ISO 17065 applying the requirements specified in ETSI EN 319 403 *OR* 5. Are licensed by WebTrust; 6. Are bound by law, government regulation, or professional code of ethics (to render an honest and objective opinion); and 7. Maintain Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage. We do some of this already when we check on an auditor's status to bring an auditor's record current in the CCADB. The edits that we'll make will just make it easier for us to go through the list above. Thoughts? Ben On Tue, Jan 26, 2021 at 1:36 PM Ben Wilson <bwil...@mozilla.com> wrote: > Thanks, Clemens. I'll take a look. > > Also, apparently my redlining was lost when my message was saved to the > newsgroup. > > I'll see if I can re-post without the text formatting of strikeouts and > underlines. > > On Tue, Jan 26, 2021 at 10:24 AM Clemens Wanko via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Hi Ben, >> looking at what was suggested so far for section 3.2, it seems that the >> BR combine and summarize under "qualified" in the BR section 8.2 what you >> and Kathleen describe with the definitions for "competent" and >> "independent" parties. >> >> Based upon that, MRSP section 3.2 could be structured in the following >> way: >> >> ***** 1st: definition of "competent party" ****** >> By "competent party" we mean... >> >> ***** 2nd: definition of "independency" ****** >> By "independent party" we mean... >> >> ***** 3rd: now refer to the BR summarizing 1 and 2 up in the term >> "qualified assessor/auditor" ***** >> By "qualified party" we mean a person or other entity or group of persons >> who meet *is meeting * the combination of the requirements defined above >> for a "competent party" and an "independent party" and as such meets >> *meeting * the requirements of section 8.2 of the Baseline Requirements. >> >> >> Further following that idea and syncing it with the wording also used by >> the BR, the current suggestion for MRSP section 3.2 could be >> revised/amended as follows: >> >> ***** >> 3.2 Auditors >> Mozilla requires that audits MUST be performed by a competent, >> independent and herewith qualified party. >> [...] >> By "competent party" we mean a person or other entity *group of persons* >> who has the proficiency and is authorized to perform audits according to >> the stated criteria (e.g., by the organization responsible for the criteria >> or by a relevant agency) and for whom is sufficient public information >> available to determine and evidence that the party is competent *has >> sufficient education, experience, and ability* to judge the CA’s >> conformance to the stated criteria. >> In the latter case, "Public information" referred to SHOULD *** -> SHALL >> - Why not being more strict here?*** include information regarding the >> party’s: >> - evidence of being bound by law, government regulation, or professional >> code of ethics; >> - knowledge of CA-related technical issues such as public key >> cryptography and related standards; >> - experience in performing security-related audits, evaluations, and risk >> analyses; and >> - honesty and objectivity *ability to deliver an opinion as to the CA’s >> compliance with applicable requirements*. >> [...] >> ***** >> >> Best regards >> Clemens >> >> _______________________________________________ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
