[cabfpub] CAB Forum Document Versioning

[i-barreira at izenpe.net]

Ok,  I understand now. I thought you meant that for every new CABF document version, all of us (CAs, auditors, standards bodies, ...) have to adopt it and update all the internal and external docs.


Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net
945067705


ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.


-----Mensaje original-----
De: Gervase Markham [mailto:gerv at mozilla.org] 
Enviado el: lunes, 28 de enero de 2013 14:04
Para: Barreira Iglesias, Iñigo; public at cabforum.org
Asunto: Re: [cabfpub] CAB Forum Document Versioning

Hi Iñigo,

On 28/01/13 11:08, i-barreira at izenpe.net wrote:
> From an standards point of view that will have implications on the 
> activities of the standardization bodies because will need to update 
> the standards everytime the CABF publishes a new version,

Why is that true?

Surely it's fine for a particular ETSI standard to reference "CAB Forum Baseline Requirements 2.6.3" for as long as it likes, until the group decides to update the ETSI standard, and then it instead references "CAB Forum Baseline Requirements 3.0.4" or whatever.

Just because the CAB Forum issues a new minor version doesn't mean that every standard has to update to use it. It may be that they do, if it fits with their update cycles, or it may be that they don't.

We are not proposing any change in the speed at which the CAB Forum makes changes to these documents. We are only proposing changes to the mechanism by which those changes are recorded.

> and in the
> case of ETSI don´t know how this will impact its activities. For those 
> CAs ETSI certified, in the certification it does not say which version 
> of the EVG or BR is used but the version of the current ETSI version 
> which includes the versions of the CABF documents.

And that would continue to be the case.

> From an auditor point of view would mean to have a deepest control of 
> what their customers have done till now and can cause different 
> behaviours when different versions of the EVG and BR are in place for 
> the same CA

I'm not sure how this problem is made worse or better by my proposal.

> So, from the CA point of view, would that mean that they need to apply 
> or confirm somehow they are "using" the new version? How often?
> Will there a mínimum version to be aceptable? Will the browsers admit 
> equally those CAs with version 1.3 for example and 1.4.7 if in a year 
> those updates have taken place and the CA is still in a lower version?

That's a matter for the browsers; again, our proposal does not make any difference here. A browser root program can already, if it so chooses, say something like "we only accept EV 1.4 with the first 3 errata".

> What will happen when a recertification comes, can the CA choose, I 
> prefer 1.4.5 than the lates 1.4.7 for this and this reason?

If they are being audited against a particular version of ETSI or WebTrust, then they would be audited against the version of the BRs/EV which that audit standard mentioned - just as happens now.

> Well, I think it´s not as easy as adding more numbers to the versions,

When you say "it's not as easy", _what_ is not as easy? What problem do you think this proposal is trying to solve?

I just want to make it easier for people to refer to a particular version of our standards. We are already making a new version every time we release an erratum - we just aren't labelling it as such.

Gerv