[cabfpub] Ballot 190 - Recording BR Version Number
wthayer at godaddy.com
Fri Jul 21 09:03:24 MST 2017
On 7/21/17, 6:22 AM, "Ryan Sleevi" <sleevi at google.com> wrote:
On Fri, Jul 21, 2017 at 12:30 AM, Wayne Thayer via Public
> [WT]Gerv’s suggestion is a reasonable interpretation, but another reasonable interpretation is that CAs must increment the version number of the BRs that they log every single time the BRs are updated, regardless of what has changed. That interpretation is arguably supported by the requirement that CA’s commit comply with the latest version of the BRs in the CPS.
I see - so the situation is not that the review is difficult or
onerous (and it's benefited by the change log in the document) - just
that after every increment of the BRs, CAs may need to update their
system to record "We comply with version Y, not version X".
Is that difficult to do? I would think it would be a routine thing
already going on today with your Compliance teams, since independent
of any changes to the language, every change requires review from
Compliance against the CP/CPS to ensure that the CA's practices and
policies do indeed coincide with what are present in the currently
[WT] The creation of a new version of the BRs is always the result of a ballot, is it not? As a CA, we carefully monitor ballots that are approved because they tell us what we need to change and when the change is required. I want to increment the logged BR version number while making the system change to comply with the ballot – isn’t that likely to happen before the new BR version actually exists for any ballot that is effective immediately following the IPR review period?
The only thing it would seem to change is that, at the end of that,
they update a single flag in the system to say "BR 1.5.0" instead of
"1.4.9". I didn't think it would be more than that?
[WT] I suppose we could code something to scrape cabforum.org looking for new BR versions, but what’s the point in that? Again, today we pay attention to ballots, not BR versions.
> It would be useful to understand, given all the existing tools and practices, what's missing.
> [WT] Updating the version number of each validation method every time the BRs change for any reason is burdensome and provides no value. What’s missing for me is a clear signaling mechanism that a material change has been made to a validation method. My original email referenced ballot 202 as a concrete example.
I'm not sure I follow this - on the material change. Isn't the
question about whether or not a change is material largely dependent
upon what an individual CA's CP/CPS states they do, and how well that
aligns or doesn't align?
[WT] If the goal of this requirement is to ensure that data collected using older, less secure methods isn’t reused, then I think it’s up to the ballot author to determine if the change is material to the security properties of the validation method.
That is, consider a change to a BR method that a CA does not use. Is
that change material or immaterial? To the CA, it's immaterial. If
only one CA uses that method, it's material to them - but can it be
said to be material to the BRs, if it affected only a single party?
We have small language corrections that affect only one party, but we
mostly treat those as immaterial - usually because it's a
clarification of intent that was well-understood by other CAs.
So that's why I struggle with material versus immaterial, and perhaps
naively assumed that upon every ballot, a CA goes through its
Practices and Policies to review the changes impact on them, and to
make the necessary changes. Ideally, they do this well before it
passes - such as during the pre-discussion phase - to inform and
enlighten whether or not it represents a material change.
[WT] I struggle with this as well, which is why I’m advocating that the ballot author, and thus voting members, make the decision by placing an explicit version number on each method
More information about the Public