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.o
