[cabfpub] Merge EV Guidelines into Baseline Requirements CP?

Sheehy, Don (CA - Toronto) dosheehy at deloitte.ca
Tue Sep 8 11:13:32 UTC 2015


As you are aware WebTrust EV is a separate service – you can see the separate audit requirements and the separate audit report. Our preference is to keep them separate.  A merger would make it far more difficult – as you are aware we have already identified issues with BR in this format  ( the mapping is not as clean as being promoted) . We combine network security with baseline and need to see those in the same format  ( as mentioned at the last face to face)
Donald E. Sheehy, CPA, CA, CISA, CRISC, CIPP/C, CITP
Partner | Enterprise Risk
Deloitte


From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of i-barreira at izenpe.net
Sent: Tuesday, September 8, 2015 4:20 AM
To: sleevi at google.com; gerv at mozilla.org
Cc: public at cabforum.org
Subject: Re: [cabfpub] Merge EV Guidelines into Baseline Requirements CP?

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

Regards

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

[Descripción: firma-email-2010]

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> [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<mailto: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.

Confidentiality Warning: 

This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank You

If you do not wish to receive future commercial electronic messages from Deloitte, forward this email to unsubscribe at deloitte.ca

Avertissement de confidentialité: 

Ce message, ainsi que toutes ses pièces jointes, est destiné exclusivement au(x) destinataire(s) prévu(s), est confidentiel et peut contenir des renseignements privilégiés. Si vous n’êtes pas le destinataire prévu de ce message, nous vous avisons par la présente que la modification, la retransmission, la conversion en format papier, la reproduction, la diffusion ou toute autre utilisation de ce message et de ses pièces jointes sont strictement interdites. Si vous n’êtes pas le destinataire prévu, veuillez en aviser immédiatement l’expéditeur en répondant à ce courriel et supprimez ce message et toutes ses pièces jointes de votre système. Merci.

Si vous ne voulez pas recevoir d’autres messages électroniques commerciaux de Deloitte à l’avenir, veuillez envoyer ce courriel à l’adresse unsubscribe at deloitte.ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150908/3038289c/attachment-0003.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/3038289c/attachment-0003.jpg>


More information about the Public mailing list