[cabfpub] CAB Forum Document Versioning

Sheehy, Don (CA - Toronto) dosheehy at deloitte.ca
Tue Jan 29 21:34:50 UTC 2013


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.


More information about the Public mailing list