Re: Key-destruction audit web-trust vs. ETSI (RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert)
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 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=g> > 91058 Erlangen, Germany > <https://www.google.com/maps/search/Freyeslebenstr.+1+%0D%0A91058+Erlangen,+Germany?entry=gmail=g> > Tel.: +49 1522 2894134 > mailto: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 > *Sent:* Samstag, 4. Juli 2020 16:37 > *To:* Buschart, Rufus (SOP IT IN COR) > *Cc:* Peter Bowen ; > 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 > wrote: > > Dear Ryan! > > > From: dev-security-policy > On Behalf Of Ryan Sleevi via dev-security-policy > > Sent: Freitag, 3. Juli 2020 23:30 > > To: Peter Bowen > > Cc: Ryan Sleevi ; Pedro Fuentes ; > 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 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 totall
RE: Key-destruction audit web-trust vs. ETSI (RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert)
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 91058 Erlangen, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.twitter.com/siemens<http://www.twitter.com/siemens> www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> [cid:image001.gif@01D6525A.EA305A60] 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 Sent: Samstag, 4. Juli 2020 16:37 To: Buschart, Rufus (SOP IT IN COR) Cc: Peter Bowen ; 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 mailto:rufus.busch...@siemens.com>> wrote: Dear Ryan! > From: dev-security-policy > mailto: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 mailto:pzbo...@gmail.com>> > Cc: Ryan Sleevi mailto:r...@sleevi.com>>; Pedro Fuentes > mailto:pfuente...@gmail.com>>; > mozilla-dev-security-pol...@lists.mozilla.org<mailto: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 > mailto: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 accred
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 wrote: > Dear Ryan! > > > From: dev-security-policy > On Behalf Of Ryan Sleevi via dev-security-policy > > Sent: Freitag, 3. Juli 2020 23:30 > > To: Peter Bowen > > Cc: Ryan Sleevi ; Pedro Fuentes ; > 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 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