[cabfpub] CAB Forum Document Versioning

[Rich Smith]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20130129/d8ec4ba7/attachment-0001.bin