Re: Key-destruction audit web-trust vs. ETSI (RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert)

[Ryan Sleevi via dev-security-policy]

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
> 
> 91058 Erlangen, Germany
> 
> Tel.: +49 1522 2894134
> mailto:rufus.busch...@siemens.com 
> www.twitter.com/siemens
> www.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 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 

RE: Key-destruction audit web-trust vs. ETSI (RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert)

[Buschart, Rufus via dev-security-policy]

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

Re: Key-destruction audit web-trust vs. ETSI (RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert)

[Ryan Sleevi via dev-security-policy]

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 

Key-destruction audit web-trust vs. ETSI (RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert)

[Buschart, Rufus via dev-security-policy]

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.

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

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy