On Wed, Jun 24, 2020 at 3:08 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> I have updated the following section of the wiki page to incorporate > feedback that I received from representatives of ACAB'c. > > > https://wiki.mozilla.org/CA/Audit_Statements#Verifying_ETSI_Auditor_Qualifications > > I will greatly appreciate it if those of you familiar with ETSI audits > will review it and provide feedback. While browsers have certainly discussed requiring ACAB’c membership, and rejecting audits from CAs that are not members, I haven’t seen much transparency yet from ACAB’c about how they supervise and/or review audits in the same way WebTrust does. It also runs a risk with respect to trusting a third-party organization to validate the qualifications. I could totally understand and agree that if ACAB’c membership was mandatory, because of some clear value to browsers such as Mozilla, this would make sense, but right now it seems like it may be premature? For example, as noted by ACAB’c itself, accreditation is with respect to ISO 17065 and eIDAS Art3.18, but that provides zero guarantees with respect to certificates, the BRs, or to the ETSI EN 319 403 provisions. For example, if a notified scheme under eIDAS made use or certificates in a way that is directly in conflict with Mozilla, those auditors could still be seen as skilled to assess Mozilla’s requirements. That seems... odd? I would suggest that, for the time being, ACAB’c isn’t a shortcut. I realize that means more work for Mozilla, and broadly for the industry, but it might provide an opportunity for ACAB’c to focus on whether the goal is to support eIDAS audit schemes and accreditation, or whether it is to provide browsers equivalent confidence and focused collaboration in the way the WebTrust TF had engaged in. That isn’t to suggest the auditors might not also provide eIDAS audits, but it seems a real missed opportunity for auditors to more proactively engage and ensure needs like Mozilla’s are met. I realize the template is a valuable step, but I don’t think ACAB’c membership alone is equivalent to the assurances browsers get from WebTrust licensure, and I worry that the “simple” step will encourage auditors that are not appropriately qualified for browser use cases. I know this means considerably more work for Mozilla, to disregard ACAB’c for the time being, and so I don’t want to seem dismissive of that. If anything, my hope is it might encourage more engagement by ACAB’c here, and a more careful evaluation of membership, criteria, and focus, such that the end state is we can skip the NAB/CAB validation and instead be confident that ACAB’c membership is a useful and positive signal of auditor qualification. I just don’t know that we’re there yet, and I worry ACAB’c might be just a little too eager, and a little too generalized, right now :) > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
