On Sat, Jul 4, 2020 at 9:17 AM Buschart, Rufus <rufus.busch...@siemens.com> wrote:
> Dear Ryan! > > > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Ryan Sleevi via dev-security-policy > > Sent: Freitag, 3. Juli 2020 23:30 > > To: Peter Bowen <pzbo...@gmail.com> > > Cc: Ryan Sleevi <r...@sleevi.com>; Pedro Fuentes <pfuente...@gmail.com>; > mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the > Dangerous Delegated Responder Cert > > > > On Fri, Jul 3, 2020 at 4:19 PM Peter Bowen <pzbo...@gmail.com> wrote: > > > I agree that we cannot make blanket statements that apply to all CAs, > > > but these are some examples where it seems like there are alternatives > > > to key destruction. > > > > > > > Right, and I want to acknowledge, there are some potentially viable > paths specific to WebTrust, for which I have no faith with respect > > to ETSI precisely because of the nature and design of ETSI audits, that, > in an ideal world, could provide the assurance desired. > > Could you elaborate a little bit further, why you don't have "faith in > respect to ETSI"? I have to admit, I never totally understood your concerns > with ETSI audits because a simple comparison between WebTrust test > requirements and ETSI test requirements don't show a lot of differences. If > requirements are missing, we should discuss them with ETSI representatives > to have them included in one of the next updates. ETSI ESI members, especially the vice chairs, often like to make this claim of “simple comparison”, but that fails to take into account the holistic picture of how the audits are designed, operated, and their goals to achieve. For example, you will find nothing to the detail of say the AICPA Professional Standards (AT-C) to provide insight into the obligations about how the audit is performed, methodological requirements such as sampling design, professional obligations regarding statements being made which can result in censure or loss of professional qualification. You have clear guidelines on reporting and expectations which can be directly mapped into the reports produced. You also have a clear recognition by WebTrust auditors about the importance of transparency. They are not a checklist of things to check, but an entire set of “assume the CA is not doing this” objectives. And even if all this fails, the WebTrust licensure and review process provides an incredibly valuable check on shoddy auditors, because it’s clear they harm the “WebTrust brand” ETSI ESI-based audits lack all of that. They are primarily targeted at a different entity - the Supervisory Body within a Member State - and ETSI auditors fail to recognize that browsers want, and expect, as much detail as provided to the SB and more. We see the auditors, and the TC, entirely dismissive to the set of concerns regarding the lack of consistency and transparency. There is similarly no equivalent set of professional standards here: this is nominally handled by the accreditation process for the CAB by the NAB, except that the generic nature upon which ETSI ESI audits are designed means there are few normative requirements on auditors, such as sampling and reporting. Unlike WebTrust, where the report has professional obligations on the auditor, this simply doesn’t exist with ETSI: if it isn’t a checklist item on 319 403, then the auditor can say whatever they want and have zero professional obligations or consequences. At the end of the day, an ETSI audit, objectively, is just a checklist review: 403 provides too little assurance as to anything else, and lacks the substance that holistically makes a WebTrust audit. It is a comparison of “paint by numbers” to an actual creative work of art, and saying “I don’t understand, they’re both use paint and both are of a house”. And while it’s true both involve some degree of creative judgement, and it’s up to https://mobile.twitter.com/artdecider to sort that out, one of those paintings is more suited to the fridge than the mantelpiece. The inclusion of the ETSI criteria, back in v1.0 of the Mozilla Root Store Policy in 2005, wasn’t based on a deeply methodical examination of the whole process. It was “Microsoft uses it, so they probably found it acceptable”. And it’s continuance wasn’t based on it meeting needs, so much as “it’d be nice to have an alternative to WebTrust for folks to use”. But both of those statements misunderstood the value ETSI ESI audits provide and the systemic issues, even if they were well-intentioned. The contemporary discussions, at that time, both of Scott Perry’s review (and acceptance) as an auditor independent of the WebTrust/ETSI duo and of the CACert audit, provide ample insight into the expectations and needs. I don’t dismiss ETSI ESI for what it is trying to do: serve a legal framework set of objectives (eIDAS, which is itself neutral with respect to ETSI ESI audit schemes, as we see from the currently notified schemes). But that’s not what we’re trying to do, not what we need, and certainly lacks the body of supporting documents that provide transparency how audits are conducted, the professional consequences as to misrepresentation, and the engagement and agility we need to address these challenges. That ETSI ESI is still dismissive of the need for documenting incident reports in the audits, for example, simply highlights the continued throwing of good money after bad. And honestly, that’s OK: ETSI ESI and the Supervisory Bodies can work that out. The NAB/CAB Inconsistency among member states is clearly an issue of concern for ENISA and the EC, because it means their needs aren’t met. But there’s nothing at all to suggest that because ETSI made a checklist that looks like WebTrust’s checklist that they are, at all, remotely comparable. It is, in my view, no different than if someone came to m.d.s.p. and would like to be an auditor because, look, they have a checklist! And all their friends trust them, so you know they’re trustworthy! Yet that’s what happened with ETSI audits, and I strongly believe it was a mistake. Nominally, this would be an area that ACAB’c can step in, except you realize it’s the same folks and the same problems. See the thread re: ACAB’c in which we’re still in the place where a claim is made “Ah, we do something, that’s why we’re trustworthy” and I have to point out public contradictions to that. We can debate the merits of these statements, as I’m sure some auditors will jump in and do so, but my original point was one predicated on a lack of transparency and accountability by ETSI auditors that would remotely raise to the same level of assurance that we would see from AICPA, CPA Canada, or ISAE. ETSI is 100 years behind in having that body of documented evidence and procedure. And that absence is important enough that I don’t think the continued acceptance of ETSI audits should be a goal. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
