[cabfpub] Auditability of EV 1.4 and other CABF Guidelines

Fri Nov 9 23:12:53 UTC 2012

Thanks, Don.  I’m just thinking out loud here, but what if we were to start
working toward a two-session model for ballots and effective dates?  Session
1 would be Feb1-May30 for ballots, and any effective date would be the
following Oct. 1?  Or for items that take longer to implement or require
more modifications to audit criteria, the effective date would be the
following May 1st?  Session 2 for ballots would be Aug15th-Nov15th and any
effective date would be the following May 1 (or the following Oct 1, for
more complex changes)?  

We’d have recesses from Guideline-based ballots from Nov. 15 through January
30 and from June 1 through Aug 15th.

Then we’d work toward having CABF Guidelines locked down (or at least as
stable as possible during those periods, in terms of potential changes and
effective dates) so that there were periods during which requirements
weren’t moving targets for CA implementation changes or audit criteria?  If
this suggestion doesn’t work, either because it takes longer to implement
and then audit or because sometimes no audit criteria need to be changed,
which dates/cycles would be best from an audit criteria / CA practices
perspective?   Or is a single yearly cycle, like every July 1st, a better
approach for ETSI and WebTrust audit-criteria updating?

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Sheehy, Don (CA - Toronto)
Sent: Friday, November 09, 2012 3:43 PM
To: ben at digicert.com; public at cabforum.org
Subject: Re: [cabfpub] Auditability of EV 1.4 and other CABF Guidelines

This is my opinion only at this point – 

The only issue Ben is that WebTrust for CA is also used for CAs that do not
issue EV certs , and others that are not public.

I don’t believe that we could ever get to one framework fits all – there
would be too many “not applicables” but yet the seal would look the same –
causing some confusion

I see Baseline being incorporated at some point in the future – once all the
kinks are worked out. We have talked about that in the face to face

EV is definitely a separate service

Security – we will be working that into WebTrust 2.1 – but that will just
apply to public issuing certs – the same group that it is targeted to

But I agree that the haste to create new versions needs to slow
 before we
have 1,0 audits in baseline we need to develop and issue 1.1

Don 

Donald E. Sheehy, CA·CISA, CRISC, CIPP/C 
Partner | Enterprise Risk 
Deloitte

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ben Wilson
Sent: Friday, November 09, 2012 11:51 AM
To: public at cabforum.org
Subject: [cabfpub] Auditability of EV 1.4 and other CABF Guidelines

All,

The removal of some of the identical provisions from the EV Guidelines
(v.1.4) and replacing them with cross-references to the Baseline
Requirements has added a degree of complexity to the maintenance of audit
criteria for the EV Guidelines.  Presently, and in the future, I think we
need to make a better effort to communicate and coordinate with ETSI and
WebTrust about our documents so that we facilitate the synchronization of
our requirements with their audit criteria.  You’ll note that our more
recent ballots passing major revisions of guideline documents specified that
we would work with ETSI and WebTrust to achieve this coordination /
synchronization.  For example, the May 29, 2012 EV criteria that were
referenced to baseline criteria (effective July 1, 2012) and further
modified under version 1.1 (effective September 14, 2012) have created a
moving target.  Now, when we make revisions to the Baseline Requirements,
the EV Guidelines are also effectively changed.   We need to work on a
formalized document release cycle that does not have effective dates all
over the place, and which stays in pace with the ETSI and WebTrust
criteria-adoption cycles.  It would be good to form a committee to work on
this issue.  Specifically, a primary objective of the charter for such
working group would be to ensure that the next full release of a CAB Forum
document contemplates ahead of time the ETSI and WebTrust versions in which
those criteria will appear and become auditable.  The work of such committee
is essential for the development of an understandable and globally
consistent set of audit criteria.  One thing for such committee to consider
in working with ETSI and WebTrust is the extent to which our Baseline
Requirements can serve as the “flagship” of an audit scheme.  I would
envision a future where “WebTrust for CAs”  and the comparable ETSI audit
serves as the primary framework (without having a special “Baseline
Requirements” WebTrust seal, unless it says something along the lines of
“WebTrust for CAs +BR +EV”).  Does that make sense?  In other words, we need
to take our Baseline Requirements, EV Guidelines, and Security document, and
see what the deltas are among WebTrust  and ETSI requirements, as well as
the various root inclusion programs of Mozilla, Microsoft, Opera, etc.
Otherwise, we’re going to be causing ourselves nothing but heartache as we
attempt to improve CA industry practices because we will have members (and
those who are not members of the Forum) engaging in different practices
(whether for competitive advantage or merely due to ignorance).

Ben Wilson

CAB Forum Chair

  _____  

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. 
Information confidentielle: Le présent message, ainsi que tout fichier qui y
est joint, est envoyé à l'intention exclusive de son ou de ses
destinataires; il est de nature confidentielle et peut constituer une
information privilégiée. Nous avertissons toute personne autre que le
destinataire prévu que tout examen, réacheminement, impression, copie,
distribution ou autre utilisation de ce message et de tout fichier qui y est
joint est strictement interdit. Si vous n'êtes pas le destinataire prévu,
veuillez en aviser immédiatement l'expéditeur par retour de courriel et
supprimer ce message et tout document joint de votre système. Merci. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121109/a7e198f6/attachment-0004.html>