On Mon, Jul 20, 2020 at 10:27 AM Arvid Vermote via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> ACAB'c is a group of a few eIDAS CABs working together for reasons, they > do not represent all eIDAS CABs neither do they have any recognized or > official function within the eIDAS ecosystem. > Can the ACAB'c member list be relied upon as being accurate and providing > correct and latest information on the accreditation status of member CABs? > It’s a manual list maintained based on membership applications and their > acceptance. Isn't the only current accurate source of accredited eIDAS CAB > the 20+ governmental NABs of participating EU countries that are designated > to accredit and supervise eIDAS CAB? > > Without any visible added value or clear and transparent insights on what > supervisory function they perform within the context of the WebPKI > ecosystem (filtering which eIDAS CAB and reports are > acceptable/qualitiative?), why would a specific subset of eIDAS CAB be > promoted over other eIDAS CAB? Parties that are interested in becoming a > WebPKI CA or maintaining that status often go look at root program > requirements as a first source to understand what needs to be done, > including what audit attestations that need to be obtained and which > parties can provide these. > > I have difficulties understanding what current reason there is to refer to > the ACAB'c and why the "simplified check" seems to suggest only ACAB'c > member audit reports are accepted. So, I think you make some great points, but I also think this highlights some confusion that might be worth addressing. Why would their role within the eIDAS ecosystem have any bearing? We know that the eIDAS ecosystem is an alternative trust framework for solving a different set of problems than browsers are trying to solve. Which is totally OK, but like... it's a bit like saying "The ACAB'c doesn't have a recognized or official function within the Adobe Document Signing Trust Framework" and... so? I think it's reasonable to imagine that if ACAB'c were to provide a similar model as WebTrust, there might be value in deferring to them *instead of* the eIDAS ecosystem. I do believe it's entirely a mistake to defer to the eIDAS ecosystem at all, presently, for the same reason I think it'd be a mistake to defer to, say, the banking industry's use of ISO 21188 or the ASC X.9 work. They're separate PKIs with separate goals, and it's totally OK for eIDAS to do their thing. If ACAB'c were, as you suggest, to provide filtering of reports, provide normative guidance and enforcement in the same way that, say, AICPA or CPA Canada provide with respect to their practitioner standards, and similarly provide a level of assurance similar to WebTrust licensure, it could make sense. But I think your criticisms here of ACAB'c are equally criticisms that could be lobbed at WebTrust, since it's "just" a brand by CPA Canada, and in theory, "any" auditor participating under IFAC 'could' also provide audits. That's no different than the discussion here. However, I do think you're right, whether intentional or not, in pointing out that the eIDAS ecosystem lacks many of the essential properties that a _browser_ trust framework relies upon, and that's why I again suggest that the degree to which ETSI-based audits are accepted should be strongly curtailed, if not outright prevented. There are too many gaps in the professional standards, both within ETSI and within the underlying ISO standards that ETSI builds upon, to provide sufficient assurance. Pivoting to browser-initiated and/or browser-contracted audits is perhaps the single most impactful move that could be made with audits. Second to that is the WebTrust TF's Detailed Control Reports, which I believe should be required of all CAs. I don't believe ETSI is even capable of producing a remotely comparable equivalent. This is because ETSI is not a group of CABs with professional expertise, but an otherwise 'neutral' (albeit pay-to-play) SDO. Browsers notable lack of absence within ETSI (in part, due to the pay-for-play nature) mean that it's unlikely ETSI will produce a standard that reflects browsers needs, but even if browsers were to participate, it would be the same amount of work as if they just produced such a document themselves with the CABs. At least, in this regard, ACAB'c has a chance of success in producing something comparable: by being CABs with a vested interest in producing a service useful to and relied upon by browsers, they may choose to engage with browsers and work to provide a useful audit and reporting framework. But, again, the eIDAS ecosystem largely has no bearing on this. Even the accreditation, against the ETSI ESI standards used to fulfill the eIDAS Regulation, doesn't really provide much assurance, as Supervisory Bodies are currently seeing. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
