That sounds like a great idea, and sounds like a good compliment to an
approach that several (Root) CAs have taken, of requiring all their
externally-operated subordinate CAs review their auditors and audit scope
with the root CAO, before finalizing the audit engagement.

An example of how the public review has been done in the past is available
at
https://groups.google.com/g/mozilla.dev.security.policy/c/sRJOPiePUvI/m/oRmRffaQmcYJ

On Thu, Nov 5, 2020 at 4:53 PM Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ben,
>
> We're concerned that these changes could unintentionally prevent many new
> auditors from being able to conduct audits, despite being Qualified
> Auditors.  The problem is that CAs will understandably be very hesitant to
> use a new auditor, as they cannot risk having an audit conducted, and then
> not accepted by Mozilla.  An unfortunate effect of that is that CAs will
> likely only consider auditors who have a previous history of being accepted
> as qualified.
>
> One potential solution is to allow CAs to ask Mozilla to "pre-vet" a
> potential auditor they would like to use.  Mozilla policy already has a
> process in the next paragraph to provide opinions on auditors who "do not
> fit the definition of Qualified Auditor" that could potentially be
> re-used.  Unfortunately, as the paragraph is currently worded, it can only
> be used for auditors who are *NOT* Qualified, which is really weird.
>
> It would be helpful to clarify that CAs MAY use the same procedure to work
> with Mozilla to determine whether a particular auditor is Qualified or not,
> prior to the beginning an engagement.
>
> -Tim
>
> > -----Original Message-----
> > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org>
> On
> > Behalf Of Ben Wilson via dev-security-policy
> > Sent: Tuesday, November 3, 2020 6:53 PM
> > To: Mozilla <mozilla-dev-security-pol...@lists.mozilla.org>
> > Subject: Policy 2.7.1: MRSP Issue #192: Require information about auditor
> > qualifications in the audit report
> >
> > Historically, Mozilla Policy required that CAs "provide attestation of
> their
> > conformance to the stated verification requirements and other operational
> > criteria by a competent independent party or parties with access to
> details of
> > the CA's internal operations."
> > https://wiki.mozilla.org/CA:CertificatePolicyV1.0  "Competency" was "for
> > whom there is sufficient public information available to determine that
> the
> > party is competent to judge the CA's conformance to the stated criteria.
> In the
> > latter case the 'public information' referred to should include
> information
> > regarding the party's:
> >
> >    - knowledge of CA-related technical issues such as public key
> >    cryptography and related standards;
> >    - experience in performing security-related audits, evaluations, or
> risk
> >    analyses; *and*
> >    - honesty and objectivity."
> >
> > Today, section 3.2 of the MRSP
> > <https://www.mozilla.org/en-US/about/governance/policies/security-
> > group/certs/policy/#32-auditors>
> > states, "In normal circumstances, Mozilla requires that audits MUST be
> > performed by a Qualified Auditor, as defined in the Baseline Requirements
> > section 8.2," but under section 2.3 <https://www.mozilla.org/en-
> > US/about/governance/policies/security-group/certs/policy/#23-baseline-
> > requirements-conformance>,
> > "Mozilla reserves the right to accept audits by auditors who do not meet
> the
> > qualifications given in section 8.2 of the Baseline Requirements, or
> refuse
> > audits from auditors who do."
> >
> > Section 8.2 of the Baseline Requirements states an auditor must have:
> > 1. Independence from the subject of the audit; 2. The ability to conduct
> an
> > audit that addresses the criteria specified in an Eligible Audit Scheme
> (see
> > Section 8.1); 3. Employs individuals who 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. (For audits conducted in accordance with any one of the ETSI
> > standards) accredited in accordance with ISO 17065 applying the
> requirements
> > specified in ETSI EN 319 403; 5. (For audits conducted in accordance
> with the
> > WebTrust standard) licensed by WebTrust; 6. Bound by law, government
> > regulation, or professional code of ethics; and 7. Except in the case of
> an
> > Internal Government Auditing Agency, maintains Professional
> Liability/Errors
> > & Omissions insurance with policy limits of at least one million US
> dollars in
> > coverage
> >
> > It is proposed in Issue #192
> > <https://github.com/mozilla/pkipolicy/issues/192> that information about
> > individual auditor's qualifications be provided--identity, competence,
> > experience and independence. (For those interested as to this
> independence
> > requirement, Mozilla Policy v.1.0 required either disclosure of the
> auditor's
> > compensation or the establishment that the auditor "is bound by law,
> > government regulation, and/or a professional code of ethics to render an
> > honest and objective judgement regarding the CA.")
> >
> > While subsection 3 of BR 8.2 requires "individuals who have proficiency
> in
> > examining Public Key Infrastructure technology, information security
> tools and
> > techniques, information technology and security auditing, and the
> third-party
> > attestation function," that fact needs evidence in order to be
> established. The
> > proposed resolution of this Issue #192 intends to accomplish that.
> >
> > This proposal to require disclosure of individual auditor qualifications
> is very
> > similar to the approach adopted by the U.S. Federal PKI
> > <https://www.idmanagement.gov/wp-
> > content/uploads/sites/1171/uploads/fpki-annual-review-requirements.pdf>
> > (see Appendices B-1 and C). E.g., "Did each Audit Opinion Letter
> identify the
> > auditor and the individuals performing the audit?"  In practice, the
> information
> > about auditor qualifications could be in the form of a separate
> document, such
> > as a curriculum vitae.
> >
> > Some initial, draft language to address this issue is located here:
> > https://github.com/BenWilson-
> > Mozilla/pkipolicy/commit/d0da7cb2b6db38e66c3a72e5c1db0e78e91d8df6
> >
> > A new subsection 3. would be added to the list of audit requirements that
> > would require "[the] name(s) and qualifications of individuals
> performing the
> > audit, as required by section 3.2" and a new paragrpah would be added to
> > section 3.2 that would say, "A Qualified Auditor MUST have relevant IT
> > Security experience, or have audited a number of CAs, and be independent
> > and not conflicted. Individuals have competence, partnerships and
> > corporations do not. Audit documentation of individual auditor
> qualifications
> > MUST be provided to Mozilla that is sufficient for Mozilla to determine
> the
> > competence, experience, and independence of the Qualified Auditor.
> Mozilla
> > will review each individual auditor’s credentials and ensure that any
> Qualified
> > Auditor has the collective set of skills required by section 8.2 of the
> Baseline
> > Requirements."
> >
> > Please provide your comments and suggestions in response to this email.
> >
> > Thanks,
> >
> > Ben
> > _______________________________________________
> > 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
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to