[cabfpub] RV: [cabfman] Ballot 171? for updating the ETSI standards in the CABF documents

Ryan Sleevi sleevi at google.com
Tue Jun 14 16:15:00 UTC 2016

On Tue, Jun 14, 2016 at 12:42 AM, Barreira Iglesias, Iñigo <
i-barreira at izenpe.eus> wrote:

> Ryan,
> A CA that wants to issue EV certs need to be audited against 411-1 for the
> EVCP policy and that implies that also have to “pass” the 401, which is the
> generic for all type of TSPs and include for example all the network
> security requirements specified by the CAB Forum.
> If a CA wants to issue QWACs, have to be audited against 411-2 for the
> QCPw policy, which takes by reference the 411-1 and also the 401. This is
> something similar of what Webtrust does if you feel more confortable.

It isn't, which is my point. These are fundamentally different approaches.

I'm much more inlined to suggest only 411-1 should be recognized. Having
411-2 incorporate 411-1 by reference makes it difficult to ascertain when
411-1 applies or when 411-2 has imposed restrictions counter with or
superior to 411-1, whereas it's much easier to objectively state compliance
with 411-1, and (from a root store perspective) to evaluate the
stipulations of 411-1 in the context of the EV Guidelines, as well as any
future updates.

That is, I'm uncomfortable with fully delegating out the task of verifying
that 411-2 doesn't do anything in conflict with 411-1, especially when CAs
are involved in drafting and developing 411-2 (which is also different than
how the WebTrust work is developed)

> For example, Izenpe, is going to get audited against 411-1 for the DV, OV
> and EV policies and also against 411-2 for the QCPw policy. If we had the
> intention of only issue QCs because as EU CA can make it, then, we´ll have
> only the 411-2 and that does not mean that, even 411-2 for QCPw uses mostly
> of the requirements of the EVCP in 411-1, I can issue EV certs. So, a CA
> that want to issue EV certs has to be audited against 411-1, a CA that want
> to issue EV and QCPW has to be audited against 411-1 and 411-2, and if only
> wants to issue QCPw, then only 411-2 which in any case will have to follow
> what everything that is stated in 401 and 411-1.

I suppose put differently, since we're still talking past eachother, I
questioning whether QCPw under 411-2 would result in Izenpe being able to
apply for EV status with the QCPw OID. I am suggesting no, it would not be
sufficient - that in order to have QCPw (audited under 411-2) recognized as
EV, Izenpe would also need to undergo a 411-1 audit, for the EVCP, and then
assert that the QCPw certs were also EVCP certs. Then, the EV recognition
would be based on the EVCP OID, and not the QCPw OID.

In effect, I'm suggesting no special treatment or recognition for QCPw /
411-2, and that the only thing that matter to root programs is 411-1 with
EVCP with respect to EV. Similarly, if a CA presented a 411-2 audit only,
with no 411-1 audit, it wouldn't intrinsically be included. The CA would
also have to undergo a 411-1 audit, for DVCP/PTC-BR (at a minimum)

I'm expressly uncomfortable with the notion on additional audit schemes
that partially incorporate by reference the baselines as being considered
equivalent; it places additional burden during the evaluation of audits to
examine the audit criteria to see if the supplementary scheme (e.g. QCPw)
fully complies with the base scheme (PTC-BR/DVCP/EVCP), and that's not a
cost that seems to provide benefits to the ecosystem at large.

> OTOH, I´d like to clarify that Webtrust is one thing and ETSI is another
> one, and you all can´t compare all the time or try to “understand” what
> ETSI does on the way Webtrust does. But in any case, at the end, both
> schemes check/assess the same things.

I don't think that's been in question. However, I was trying to illustrate
the principles at play here, since regardless of the approach - WebTrust or
ETSI - they serve a valuable role.

> So if a non EU CA wants to issue QCPw it has to follow what the 411-2
> says, which by default, will look at 411-1 and 401.

And this is what I have issue with.

> And finally, the intention of this ballot is just to replace an obsolete
> ETSI standard for the newest one which includes all CABF requirements and
> provides a better clarification on the audit stuff which was the major
> concern during the past 2 years for the browsers. If there´s a specific
> point that needs to clarify just let me know and we can rephrase it to make
> it clear.

Again, let me repeat: I'm not supportive of adding 411-2 to the list of
documentation. And Erwann has also pointed out specific concerns to
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160614/4ab304a2/attachment-0003.html>

More information about the Public mailing list