Hi Clemens, I think this fundamentally misunderstands the proposal. As Ben mentioned, and as countless other schemes have highlighted, competency is with individuals, not organizations. While the eIDAS Scheme is relevant for eIDAS qualification, I think it's important to highlight that browsers are not, nor have they ever, relied upon the Qualified Trust List, nor on the eIDAS Framework, as they are fundamentally separate trust frameworks. I understand you see this redundant, but given that browsers are not relying on the Supervisory Body function, since they are different trust frameworks, it's absolutely vital for transparency to be able to provide that information.
While something may be acceptable for the eIDAS Certification scheme, audits exist to support those consuming them, and it's important to make sure they are addressed. WebTrust equally has an approach like you describe, but what is being suggested here is that is not sufficient for the need and use case, and I fully support that. I can understand that professional accountability is scary, because it might mean that audits that might be acceptable for eIDAS are rejected as unacceptable for Mozilla, but again, that's a reflection of the different nature of trust frameworks. I find the appeal to redundancy and the NAB, and further, the suggestion of GDPR, to be a bit insulting to this community. This opposition to transparency fundamentally undermines the trust in ETSI provided audits, or this appeal to the eIDAS scheme, which has limited relevance given it's a fundamentally different audit scheme, beggars belief. If you'd like to raise Fear/Uncertainty/Doubt about GDPR, I believe you owe this community a precise and detailed explanation about what you believe, relevant to the auditor professional experience, would be problematic. The suggestion here that this is somehow unique or untowards is deeply concerning. I note, for example, that BSI's own C5 controls are designed around transparency, and Section 4.4.9 on auditor qualification similarly places provisions for transparency. Without making an appeal to either the NAB or the Supervisory Body, both of which are relevant for eIDAS but not acting in a function for browser trust frameworks (nor can they), what alternative would you propose to help community members here have verifiable evidence and confidence in the auditor's qualifications? On Thu, Nov 5, 2020 at 10:54 AM Clemens Wanko via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ben, > in order to avoid for every single audit the compilation work for the > auditor (in person) on his qualification, independence, etc. as well as the > need to crosscheck the statements he made, that was covered for the EU > ETSI/eIDAS scheme by the accreditation of the body (organization; example: > I am member/employee of TUV Austria CERT as accredited body) employing and > using that auditor (in person) for a specific audit. The body will > receive/keep its accreditation only in case it proves in annual audits with > its accreditation body, that the following auditor related aspects were > covered in the audit projects performed throughout the past audit period: > > ISO/IEC17065 - I listed the relevant chapters only: > 6 Resource requirements ............................... 31 > 6.1 Certification body personnel ....................... 31 > 6.1.1 General .......................................................... 31 > 6.1.2 Management of competence for personnel involved in the certification > process ......................................................... 31 > 6.1.3 Contract with the personnel ........................ 33 > 6.2 Resources for evaluation............................. 33 > 6.2.1 Internal resources ........................................ 33 > 6.2.2 External resources (outsourcing) ............... 33 > > …amended by guidance documentation in the following areas: > Annex A (informative) Principles for product certification bodies and > their certification activities ................................... 63 > A.1 General .......................................................... 63 > A.2 Impartiality .................................................... 63 > A.3 Competence .................................................. 65 > A.4 Confidentiality and openness ..................... 65 > A.4.1 General .......................................................... 65 > A.4.2 Confidentiality .............................................. 65 > A.4.3 Openness ...................................................... 65 > A.4.4 Access to information .................................. 65 > A.5 Responsiveness to complaints and appeals > .......................................................... 65 > A.6 Responsibility ............................................... 67 > > For ETSI/eIDAS auditors the ISO/IEC17065 is detailed by the following > mandatory ETSI EN 319 403 (updated version: ETSI EN 319 403-1) > requirements. I listed the relevant chapters only: > “Electronic Signatures and Infrastructures (ESI); Trust Service Provider > Conformity Assessment; Part 1: Requirements for conformity assessment > bodies assessing Trust Service Providers”: > 6 Resource requirements > ........................................................................................................................... > 11 > 6.1 Conformity Assessment Body personnel > ......................................................................................................... > 11 > 6.1.1 General > ........................................................................................................................................................ > 11 > 6.1.2 Management of competence for personnel involved in the audit > process................................................... 11 > 6.1.2.0 General requirements > ............................................................................................................................ > 11 > 6.1.2.1 Management of > competence.................................................................................................................. > 11 > 6.1.2.2 Training of audit teams > ......................................................................................................................... > 12 > 6.2 Resources for evaluation > .................................................................................................................................. > 12 > 6.2.0 General requirements > .................................................................................................................................. > 12 > 6.2.1 Internal resources > ........................................................................................................................................ > 12 > 6.2.1.0 General requirement > .............................................................................................................................. > 12 > 6.2.1.1 Competence of Conformity Assessment Body personnel > ..................................................................... 12 > 6.2.1.2 Competences for all functions > ............................................................................................................... > 12 > 6.2.1.3 Competences for application review > ..................................................................................................... > 13 > 6.2.1.4 Competences and prerequisites for > auditing.......................................................................................... > 13 > 6.2.1.5 Competences for review > ........................................................................................................................ > 13 > 6.2.1.6 Competences for certification decision > ................................................................................................. > 14 > 6.2.1.7 Competences for Technical Experts > ...................................................................................................... > 14 > 6.2.1.8 Audit team > ............................................................................................................................................. > 14 > 6.2.1.9 Audit team leader > .................................................................................................................................. > 15 > … > Annex A (informative): Auditors' code of conduct > .............................................................................. > 25 > > For audits performed by ISO17065/ETSI EN 319 403 accredited bodies it is > therefore ensured, that the requested auditors properties you refer to are > guaranteed. We deem it redundant to require the auditor acting for the > accredited body to provide corresponding statements again. Furthermore we > believe that repetition would not provide additional/better assurance. > Apart from that we expect GDPR trouble in case the accredited body > publishes personal auditor information. > > All the best > Clemens (TUV Austria & ACAB’c member) > > > On Wednesday, 4 November 2020 at 00:53:52 UTC+1, Ben Wilson wrote: > > 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
