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

Barreira Iglesias, Iñigo i-barreira at izenpe.eus
Tue Jun 14 00:42:20 MST 2016


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.

And, yes, a CA that is audited under 411-2 for QCPw should have no problem to also get audited in 411-1 for the EVCP, but that´s a business decision. It does not mean that a CA that is audited under 411-2 for QCPw automatically grants the 411-1 for the EVCP. The CA has to have two different policies with different certificate profiles, etc. and above all, follow the law. The 411-1 is only for public key certificates and it incorporates all the requirements of the CABF BRs and EVs, but the 411-2 is for issuing EU qualified certificates, and has to follow the eIDAS regulation, and can be “used” by EU QTSPs.

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.

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.
And for the particular case of the EU qualified certs, the only standard applicable is the 411-2, Webtrust is not even recognized in the eIDAS regulation. 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 above all, is the law, so it´s not only to meet the technical stuff but also all the articles of the law and to be tied what is stated there, and for example, for an American company, well, there´s an article of signing a bilateral agreement, etc. Of course, Andrea mentioned some shortcuts, but there´s a law to follow, and that´s 411-1. So even in this particular case, EVCP vs QCPw, are very similar technically, there are some other legal implications.

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.


Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.eus<mailto:i-barreira at izenpe.eus>
945067705

[Descripción: firma_email_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: lunes, 13 de junio de 2016 14:57
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 Mon, Jun 13, 2016 at 12:40 AM, Barreira Iglesias, Iñigo <i-barreira at izenpe.eus<mailto:i-barreira at izenpe.eus>> wrote:

Inigo,

I'm not sure how this is meaningfully different than how we handle EV audits, which root stores also require the BR audits.

Same here

This doesn't answer the question, and I have no clue what you're trying to say.


I've reviewed 411-1 and 411-2, and the outstanding question you didn't answer is what prevents a CA from getting audited under EVCP when getting a QCP-w audit.

A CA can issue an EV when passes 411-1 under EVCP policy. To get a QCPw, the CA has to pass the 411-2

That's not what I'm asking about.

To get QCP-w, a CA has to pass 411-2. Yes, 411-2 tries to incorporate by reference, where applicable, 411-1. What I'm specifically asking is if a CA has to get/pass 411-2, why can they not get audited, at the same time, to 411-1 under EVCP? What prevents this?

Under the WebTrust schemes, as practiced by root stores, a CA wishing to be audited under WebTrust for CAs also gets audited under WebTrust for BRs and WebTrust. That is, three audits. (The notion of an EV-only CA is not made by root stores that I'm aware of, since to issue EV they necessarily are trusted to issue TLS).

As a root store, there's zero interest in understanding or recognizing QCP-w. So if a CA wants to be recognized as EV, it would need to present a 411-1 EVCP audit. My understanding is that a CA getting a 411-2 QCPw audit should have no trouble getting a 411-1 EVCP audit, and then there's no ambiguity that the CA is conforming to 411-1 EVCP. Why doesn't that work?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160614/52c25961/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9540 bytes
Desc: image001.jpg
Url : https://cabforum.org/pipermail/public/attachments/20160614/52c25961/attachment-0001.jpg 


More information about the Public mailing list