[cabfpub] CAB Forum Document Versioning

Rich Smith richard.smith at comodo.com
Wed Jan 30 13:25:23 UTC 2013


I think that in order to avoid the confusion we had this time as to when something is really effective, unless it is something that presents a clear security threat, the effective date should be when audit guidelines have been updated by WebTrust and ETSI.
-Rich

> -----Original Message-----
> From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
> Sent: Tuesday, January 29, 2013 6:38 PM
> To: 'Sheehy, Don (CA - Toronto)'; 'Tom Albertson';
> richard.smith at comodo.com; 'Gervase Markham'; 'CABFPub'
> Subject: RE: [cabfpub] CAB Forum Document Versioning
> 
> I think part of the problem is that the meaning behind version
> numbering is unclear. To resolve this, the guidelines could include
> both the effective date of the guideline and the date when audit
> criteria will be implemented based on the updates.  This separates the
> audit criteria date from both the effective date and version number.
> Doing so also clarifies that the CAB Forum is free to adopt guidelines
> and errata more often than July 1st of each year while alerting parties
> on when the audit criteria will be implemented.
> 
> For example, version 1.2 of the Baseline Requirements could include, on
> the title page, a statement that "The effective date of v1.2 is May 1,
> 2013. Implementation of audit criteria for version 1.2 by both WebTrust
> and ETSI is expected on January 1, 2014."
> 
> Jeremy
> 
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Sheehy, Don (CA - Toronto)
> Sent: Tuesday, January 29, 2013 2:35 PM
> To: Tom Albertson; richard.smith at comodo.com; 'Gervase Markham';
> 'CABFPub'
> Subject: Re: [cabfpub] CAB Forum Document Versioning
> 
> If we freeze at say 2.3.1 then we would develop the audit criteria
> based on 2.3.1 - not an issue at all - that would be specifically
> called out-
> 
> but if/when 2.3.2 is then released by cab ( say a month later), there
> will need to be clarity that 2.3.2 was not incorporated into audit due
> to timing [ the whole numbers produce better clarity in my opinion -
> easier for public to understand that WebTrust for EV 1.4 is based on
> 1.4 and not 1.4.1 as an example].
> 
> what will then cause the forum to move to 3.0 from a 2.3. x or will
> they stay at 2.3.x forever...?
> 
> 
> 
> Donald E. Sheehy, CPA, CA·CISA, CRISC, CIPP/C Partner | Enterprise Risk
> Deloitte
> 
> 
> 
> -----Original Message-----
> From: Tom Albertson [mailto:tomalb at microsoft.com]
> Sent: Tuesday, January 29, 2013 1:00 PM
> To: richard.smith at comodo.com; Sheehy, Don (CA - Toronto); 'Gervase
> Markham'; 'CABFPub'
> Subject: RE: [cabfpub] CAB Forum Document Versioning
> 
> The move to decimal based versioning of docs (specs) and the analogy to
> time-based software release methods may be apt - the Forum must have a
> definite date by which they complete work or "freeze" the guidelines,
> presumably each year.  Let's say the deadline for turning things over
> to audit regimes is July 1 (totally fictional, some other date may
> apply).  The last version of the CAB Base Guidelines balloted before
> this date is version 2.3.1.   The Forum needs only to decide whether to
> send version 2.3, or 2.3.1, or possibly 2.0. The Forum wants to decide
> which version is the one that should be presented to the public;
> however if I understand Don they want to freeze the audit criteria on
> whole number guidelines, versions 2.0, 3.0 and so on.
> 
> Software folks tend not to get caught up in the actual version number
> that gets shipped - we develop daily builds, and the tangible
> differences between build 8808 and 8809 are few.  Whichever we decide
> is fully baked and ready for release, it gets shipped as [Missile
> Launcher 2013].  Numbers can be deceiving if you slavishly apply them
> in wholly different contexts - there are some avid users who track
> their software right down to the build number, but there are many more
> who only install Missile Launcher 2013 without regard to the build its
> based upon.  In the Forum we should know that we are working against
> version 2.3.1, and it has a different approval status than the version
> 2.3.2, which is still under review; what the Forum hands off to the
> audit regimes need not be titled 2.3.1.  And what CAs and users
> ultimately see can be Audit Guidelines version x, incorporating the
> revisions up to 2.3.1.  Input and output - if audit regimes want to
> receive only whole number versions of guidelines, we can freeze those
> at a specific time in the calendar and call them 'version [2013], based
> on revisions 2.3.1'.  Annually produced guidelines beg for an annual
> numbering scheme, to more easily differentiate them from earlier
> versions.
> 
> Don, is that correct?  Is there an issue if when we reach some date in
> the process towards producing auditable criteria, if the Forum is
> settled on version 2.3, that you can't simply incorporate version 2.3
> into your new audit criteria?
> 
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Rich Smith
> Sent: Tuesday, January 29, 2013 8:46 AM
> To: 'Sheehy, Don (CA - Toronto)'; 'Gervase Markham'; 'CABFPub'
> Subject: Re: [cabfpub] CAB Forum Document Versioning
> 
> I agree with Don as to how and when we should expect WebTrust and ETSI
> to incorporate guidelines into their programs, but I like Gerv's idea
> from an internal management perspective.  The x.y + Errata document is
> very hard to keep track of, especially if two motions act on the same
> section(s) or a single motion acts upon many sections.  I'd like to see
> us move forward with incorporating errata directly into the document in
> a x.y.z version scheme but continue to only expect audit regimes to
> incorporate new guidelines at the point where y=y+1 (or x=x+1 in a
> major revision) and z=0 and as we've recently talked about, discuss
> with WebTrust and ETSI to come up with a reasonable fixed schedule for
> when we upgrade x or y.  There may be some cases where emergency
> situations like Debian weak keys or similar force us to take action
> outside that schedule, but by and large most motions to update the
> guidelines do not fall in that category so a 6 month or 1 year lead
> time for auditing should not be that problematic.
> Regards,
> Rich
> 
> > -----Original Message-----
> > From: public-bounces at cabforum.org [mailto:public-
> bounces at cabforum.org]
> > On Behalf Of Sheehy, Don (CA - Toronto)
> > Sent: Tuesday, January 29, 2013 11:19 AM
> > To: Gervase Markham; CABFPub
> > Subject: Re: [cabfpub] CAB Forum Document Versioning
> >
> > As mentioned a number of times in the past - formal recognition and
> > approval of Errata was done by creating a new version of EV or
> > Baseline
> > - that is what we then directed our audit efforts to. This ensured a
> > consistent audit. By adding .x to a doc every time you have an errata
> > will only create confusion as we will not issue formal guidance until
> > they move to the next approved level. As stated a number of times in
> > the past, you have to understand that we need to follow due process
> to
> > create generally accepted criteria that can be used in a public audit
> > report.
> >
> > I would propose that no change be made.
> >
> > Donald E. Sheehy, CPA, CA*CISA, CRISC, CIPP/C Partner | Enterprise
> > Risk Deloitte
> >
> >
> > -----Original Message-----
> > From: public-bounces at cabforum.org [mailto:public-
> bounces at cabforum.org]
> > On Behalf Of Gervase Markham
> > Sent: Monday, January 28, 2013 5:24 AM
> > To: CABFPub
> > Subject: [cabfpub] CAB Forum Document Versioning
> >
> > Dear CAB Forum,
> >
> > Mozilla would like to propose a change to the way we denote versions
> > of our key published documents (EV, BR, Network etc.), which we think
> > would improve matters.
> >
> > Currently, the process is that we issue an X.Y version of a document
> > every year or so, and in between we have a (perhaps poorly named, but
> > let's go with it) "errata" document which lists all of the changes,
> > updates and improvements we have agreed by ballot to make since the
> > last version was issued. You can see that process in action here:
> > https://www.cabforum.org/documents.html
> >
> > We think it would be better for us to issue a new X.Y.Z version each
> > time we agree to make a change, and post that on the website (with
> the
> > version number and date in the header of the document) under an
> > unchanging URL of this style:
> >
> > https://www.cabforum.org/EV_SSL_Latest.pdf
> >
> > as well as e.g.:
> >
> > https://www.cabforum.org/EV_SSL_1.4.7.pdf
> >
> > The advantage of this greater granularity is that it allows auditors
> > and other consumers of our documents to take our "best efforts" at
> any
> > point and use it in their process, while referring to it
> unambiguously
> > and succinctly. Currently, they have the choice of either saying:
> >
> > "We are using EV 1.4 with the Errata document which was current as of
> > 20th January 2013, which had 3 errata in it"
> >
> > which is unambiguous but highly unwieldy, or:
> >
> > "We are using EV 1.4"
> >
> > which is succinct, but means they are not getting the benefit of any
> > errata; our good work lies unused for up to a year.
> >
> > If we adopt this proposal, consumers of this document could instead
> > say, 'We are using EV 1.4.3' to indicate the third minor change to
> > version 1.4 of the guidelines, instead of mentioning an errata and
> > date. It's both succinct and unambiguous.
> >
> > We think this change would also lessen the need for rigid timetables
> > for handing documents over to auditors and others but, even if we
> > later institute such timetables, this scheme is still an improvement
> > over the status quo.
> >
> > Gerv
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org
> > https://cabforum.org/mailman/listinfo/public
> >
> >
> > 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.
> >
> >
> >
> >
> >
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org
> > https://cabforum.org/mailman/listinfo/public
> 
> 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.
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130130/bd40411e/attachment-0003.bin>


More information about the Public mailing list