[cabfpub] CAB Forum Document Versioning

Jeremy Rowley jeremy.rowley at digicert.com
Wed Jan 30 18:01:51 UTC 2013


Thanks Don.  I did not presume to speak on behalf of the audit profession.  I was merely stating my reasoning for wanting to keep the effective date of guidelines separate from the date when the audit standard based on those guidelines will be globally applied.  

Let me rephrase my previous rationale in another way: Although an audit is necessary to prove compliance to the browser, I do not think an audit is required for CAB Forum guidelines to effectively improve the industry.  I think the baseline requirements have already had a positive effect on our industry, despite the lack of an audit.  Since guidelines initiate progress within our industry when adopted, I'm not in favor of tying the effective date of documents to the date when audit criteria are made available.

Jeremy

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Sheehy, Don (CA - Toronto)
Sent: Wednesday, January 30, 2013 10:30 AM
To: jeremy.rowley at digicert.com; richard.smith at comodo.com; 'Tom Albertson'; 'Gervase Markham'; 'CABFPub'
Subject: Re: [cabfpub] CAB Forum Document Versioning

Jeremy - you need to have auditable criteria before an audit and audit opinion can be rendered under professional standards! I have said that for years ! That is the basis under which the standards that govern attestation/audit in US. Canada and international. Please do not speak on behalf of the audit profession on audit issues.

The document would not be ineffective, I agree, however, you could have a scenario that until the audit guidance is effective, there would be no requirement by the Browsers ( a key user group) that they be demonstrated as operating effectively as was the case with baseline 1.0. 

If there is a significant issue that requires an important change I agree that it should be incumbent on all to try and come up with a solution as quickly as possible. Hopefully that will not happen very often.

Don

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



-----Original Message-----
From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
Sent: Wednesday, January 30, 2013 11:04 AM
To: richard.smith at comodo.com; Sheehy, Don (CA - Toronto); 'Tom Albertson'; 'Gervase Markham'; 'CABFPub'
Subject: RE: [cabfpub] CAB Forum Document Versioning

I strongly disagree.  The auditors are not members of the CAB Forum.  They are invited guests.  As such, we should not be tying our adoption of guidelines to their schedule.  Plus, from what I understand, audit criteria are not required before a standard is auditable and an audit can look back to the practices of a CA when the guideline became effective.  A difference between the audit date and document effective date does not make the document ineffective until the audit date.

Jeremy


-----Original Message-----
From: Rich Smith [mailto:richard.smith at comodo.com]
Sent: Wednesday, January 30, 2013 6:25 AM
To: jeremy.rowley at digicert.com; 'Sheehy, Don (CA - Toronto)'; 'Tom Albertson'; 'Gervase Markham'; 'CABFPub'
Subject: RE: [cabfpub] CAB Forum Document Versioning

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

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public




More information about the Public mailing list