[cabfpub] RV: [cabfman] Ballot 171? for updating the ETSI standards in the CABF documents
Barreira Iglesias, Iñigo
i-barreira at izenpe.eus
Thu Jun 16 08:02:03 UTC 2016
411-2 says that “all the requirements defined for EVCP in ETSI EN 319 411-1 shall apply for issuing QCP-w”, so, if you feel more comfortable admitting only 411-1, I see no issue but I still don´t understand why because if a TSP only wants to issue qualified certificates, and get his audit in 411-2 for QCPw (which means that all the requirements for EVCP defined in 411-1 applies), what are you going to do with these qualified certificates? Are you going to accept it or not? If not, why?
Anyway, I can change the ballot to include only the 411-1 but would like to hear from others what´s their opinion.
Responsable del Área técnica
i-barreira at izenpe.eus<mailto:i-barreira at izenpe.eus>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.
De: Ryan Sleevi [mailto:sleevi at google.com]
Enviado el: martes, 14 de junio de 2016 18:15
Para: Barreira Iglesias, Iñigo
CC: public at cabforum.org
Asunto: Re: [cabfpub] RV: [cabfman] Ballot 171? for updating the ETSI standards in the CABF documents
On Tue, Jun 14, 2016 at 12:42 AM, Barreira Iglesias, Iñigo <i-barreira at izenpe.eus<mailto:i-barreira at izenpe.eus>> wrote:
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 resolve.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9540 bytes
More information about the Public