[cabfpub] Merge EV Guidelines into Baseline Requirements CP?

Tue Sep 8 08:20:04 UTC 2015

Hi all,

I support this proposal as I sometimes mentioned to do it. I think it has more advantages having just one document than two, for example, in terms of maintenance. 

From the Izenpe point of view it´s easier for me just having one document to follow, adapt my CP/CPS to that document following the RFC 3647.

From the ETSI perspective as the editor, this is what we have been trying to do, just have one ETSI document that covers both CABF documents, if everything is in one document, it´s easier for us to just review one document when this is updated and not check 2.

Now that the CABF BR and the ETSI EN 310 411-1 follows the RFC 3647, incorporating/merging the EV guidelines and have just one document is a great idea and would make my job at Izenpe and ETSI easier J.

Regards

Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net

945067705

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: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En nombre de Ryan Sleevi
Enviado el: lunes, 31 de agosto de 2015 21:26
Para: Gervase Markham
CC: CABFPub
Asunto: Re: [cabfpub] Merge EV Guidelines into Baseline Requirements CP?

On Mon, Aug 31, 2015 at 9:12 AM, Gervase Markham <gerv at mozilla.org> wrote:

On 31/08/15 14:57, Ben Wilson wrote:
> As I’ve looked at what is ahead of us (in the Policy Review Working
> Group), I have concluded that I’d prefer to put the EV Guidelines into
> the Baseline Requirements CP.

Kathleen's view:

"I would be OK with the EV Guidelines and the BRs being in one document,
as long at is is very clear what the additional requirements are for EV.
For instance there would need to be separate sections (or sub-sections)
that start with something common like "EV" to highlight the additional
expectations for EV."

My view is that my gut feeling is against; we should be able to manage a
few document cross-references, and these are two separate standards. But
I'd say the auditors' opinion is important.

Gerv

With respect to the Baseline Requirements and EV Guidelines, I would say one (unified) document would not terribly sadden me, and would make it somewhat easier for reviewing. From experience performing CP/CPS reviews for ETSI-audited CAs (that is, considering DVCP vs OVCP vs EVCP vs EVCP+), a unified document with clear demarcation (generally) makes it easier to review.

That said, it's likely worthwhile to consider how these documents are incorporated. For example, it's possible to do so in a way that ostensibly harms, rather than helps. Consider, for example, the incorporation of the Network & Certificate System Security Requirements published by the CA/Browser Forum. These requirements were voted on as a CA/B Forum work product, but not established as required by the root stores, notably, Mozilla. However, because these documents were incorporated into the into the "WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network Security, Version 2.0", they are de facto required, even though not so by the program requirements (indeed, there are a number of non-sensical requirements in the Network & Certificate System Security Requirements that would be suboptimal for a modern CA to enforce)

There would therefore be a similar risk that in combining these documents, either the Forum or the auditors (WebTrust, ETSI) tasked with integrating these combined documents would end up imposing more stringent requirements than actually required by the root stores. We've seen this elsewhere in past integrations (e.g. Ballot 105, which imposed a more stricter interpretation of technical constraints than present in Mozilla's Program), so care would really have to be taken.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150908/a9f302e1/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 8648 bytes
Desc: image001.jpg
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150908/a9f302e1/attachment-0002.jpg>