Indeed, you’re welcome to do so, but I also don’t think these are easily adjusted for or corrected. ETSI ESI is trying to solve a different need and use case, and it’s structure and design reflect that.
And that’s ok! There’s nothing inherently wrong with that. They are trying to develop a set of standards suitable for their community of users, which generally are government regulators. As browsers, we have different needs and expectations, reflecting the different trust frameworks. This is why I stand by my assertion that it’s almost certainly better to move off ETSI ESI, having spent a number of years trying, and failing, to highlight the areas of critical concern and importance. If the ETSI ESI liaisons have not been communicating the risk, clearly communicated for several years, that a failure to address these will ultimately lead to market rejection of using such audits as the basis for browsers’ trust frameworks, I can only say that highlights an ongoing systemic failure for said liaisons to inform both communities about developments. If the answer is “as you know, it takes time, we have many members” (as the response to these concerns frequently is answered), well, it’s taking too long and it’s time to move on. Luckily, audits are something that, like many other compliance or contracting schemes, don’t inherentl conflict. An approach that has a CA getting a WebTrust audit to satisfy browser needs and, if appropriate, an ETSI ESI to satisfy others’ needs, doesn’t seem an unreasonable thing. I can understand why it may not be desirable for a CA, but the goal is to make sure browsers have the assurance they need. On Sat, Jul 4, 2020 at 5:29 PM Buschart, Rufus <rufus.busch...@siemens.com> wrote: > Thank you Ryan for spending your 4th of July weekend answering my > questions! From my purely technical understanding, without knowing too much > about the history in the discussion between the ETSI community and you nor > about the “Überbau” of the audit schemes, I would believe that most of the > points you mentioned could be easily fixed, especially since they don’t > seem to be unreasonable. Of course, I can’t speak for ETSI but since > Siemens is a long-standing member of ETSI I’ll forward your email to the > correct working group and try to make sure that you will receive a > constructive answer. > > > > With best regards, > Rufus Buschart > > Siemens AG > Siemens Operations > Information Technology > Value Center Core Services > SOP IT IN COR > Freyeslebenstr. 1 > <https://www.google.com/maps/search/Freyeslebenstr.+1+%0D%0A91058+Erlangen,+Germany?entry=gmail&source=g> > 91058 Erlangen, Germany > <https://www.google.com/maps/search/Freyeslebenstr.+1+%0D%0A91058+Erlangen,+Germany?entry=gmail&source=g> > Tel.: +49 1522 2894134 > mailto:rufus.busch...@siemens.com <rufus.busch...@siemens.com> > www.twitter.com/siemens > www.siemens.com/ingenuityforlife <https://siemens.com/ingenuityforlife> > > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief > Executive Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. > Thomas; Registered offices: Berlin and Munich, Germany; Commercial > registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; > WEEE-Reg.-No. DE 23691322 > > *From:* Ryan Sleevi <r...@sleevi.com> > *Sent:* Samstag, 4. Juli 2020 16:37 > *To:* Buschart, Rufus (SOP IT IN COR) <rufus.busch...@siemens.com> > *Cc:* Peter Bowen <pzbo...@gmail.com>; > mozilla-dev-security-pol...@lists.mozilla.org; r...@sleevi.com > *Subject:* Re: Key-destruction audit web-trust vs. ETSI (RE: SECURITY > RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder > Cert) > > > > > > > > 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 > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmobile.twitter.com%2Fartdecider&data=02%7C01%7Crufus.buschart%40siemens.com%7C378ec95d86634b33b4d108d82029ae9d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637294710676106553&sdata=CIuHi%2BLk0I2mmSSWj71ZLWdRuZLtl9mLHwGG2Ztx07M%3D&reserved=0> > 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
