On Fri, Jul 3, 2020 at 6:14 AM clemens.wanko--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> All, > on behalf of the Accredited Conformity Assessment Bodies council we would > like to provide the following background information to the guideline > “Verifying ETSI Auditor Qualification” as stated here: > > https://wiki.mozilla.org/CA/Audit_Statements#Verifying_ETSI_Auditor_Qualifications > > The guideline explains the path for a formal verification of the > ETSI/eIDAS Auditor’s qualification through verification of corresponding > evidence. > The ACAB council is capable and happy to support this process in the > following way: > > o every CAB member of the council must be accredited according IEC/ISO > 17065 in conjunction with eIDAS Art. 3.18 and ETSI EN 319 403 or ETSI EN > 319 403-1 respectively. During the membership application and verification > process for the ACAB council, the applicant has to provide corresponding > evidence which are carefully checked. This is not what your charter says, nor what your website says. https://www.acab-c.com/app/download/5811554709/ACABc+Charter_V3.pdf https://www.acab-c.com/acab-c-members/ o ACAB’c members must incorporate and follow ETSI EN 319 403 for ETSI > audits. Especially for publicly trusted certificates, Part 2 of EN 319403 > must be followed which covers all additional requirements for Conformity > Assessment Bodies auditing Trust Service Providers that issue > Publicly-Trusted Certificates. In simple words, this means that it is > mandatory for the relevant Browser requirements incorporated by ETSI, to be > followed by an accredited CAB member of ACAB’c. This is not what your charter says. All this is considered and explicitly stated for the “Simplified check” > under 1. in the guideline: member CABs were checked following the “Standard > Check” which includes the ETSI EN 319 403 (…403-1/-2) referrer in the > accreditation documentation. The standard check is performed by ACAB’c as > described in the guideline and we certainly want to support the community > to rely on that. Hence, all CAB members of ACAB’C comply with the > accreditation requirements stated above. Where is the public evidence that this is true. I’m not disputing that this could be, and probably is, true. But there’s zero actual evidence for this that I can see, beyond your assurances here. And this is part of my abiding concern with the ETSI approach to audits, because we get grand assurances but when we actually look for them, they aren’t there. If we’re going to rely on ACAB’c, we need strong evidence of the claims here, not a well-intentioned post from an ACAB’c member. The task to verify that a conformity assessment body fulfils all normative > requirements, has necessary competences, etc. is performed by the National > Accreditation Bodies (NAB). Only if the CAB demonstrates their compliance > to the normative requirements (see above) they receive their accreditation > and/or can keep it upright. And time and time again, we’ve said that the NAB is *not* ensuring these requirements, because they aren’t as you described. The NAB ensures the requirements with respect to the notified scheme. Even if the CAB assessment is based on the ETSI assessment criteria for CABs, that still doesn’t provide any guarantee the CAB is using a scheme for assessing TSPs that is based on the ETSI criteria. The decision on the qualifications of an auditor is not done by ACAB’c but > the NAB which regularly checks the capabilities of the audit against the > requirements of EN 319 403. Citation Needed. But also, as I said above, 403 isn’t the relevant portion here. All that ACAB’c does is simplify the representation of accreditation by > bringing together information from the accreditation bodies. The full check > can always be made to confirm the information provided by ACAB’c. > > Standardisation for Trust Services (CA) under the European Scheme is > typically performed by the organizations ETSI or CEN or ISO/IEC. The ACAB > council is not a standardization organization. Yes, we know. I don’t understand why this was even included. It fits with my broader complaint against the ETSI ESI liaisons in the CABF: that every CABF, we get a recital of what ETSI is and isn’t and how NABs and CABs work, while the needs of the actual consumers go unmet and unaddressed. Look, as I said to Kathleen, I’m not unoppposed in spirit. But the statements you’ve made about what ACAB’c is, or what assurances it provides, are not backed up by what ACAB’c says and documents on its website. If the ACAB’c agrees that you’ve accurately represented things, it should be trivial to document these things within your charter. Unfortunately, for the many encouraging promises browsers have received from ACAB’c, there’s a worrying lack of substance or independent verification. The only statement supporting what you’ve claimed is as a footnote at https://www.acab-c.com that does not have support within the charter or the CoC itself. And that’s why I suggested we not rely on the Simplified way that ACAB’c proposed, because there’s nothing to support the claims, or that they’re enforced. Similarly, as with most trust, I think we need to carefully verify still; even if ACAB’c put it on a webpage, as browsers, we have no proof that ACAB’c follows that process, and we’d be accepting all the risk. Trust is something that is built over time, through repeated ongoing demonstration and commitment. While I hope we can build that with ACAB’c, in due time, these sorts of elementary issues doesn’t inspire hope like I wish it would. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
