[cabfpub] Ballot 190 - Recording BR Version Number

[Ryan Sleevi]

On Fri, Jul 21, 2017 at 12:03 PM, Wayne Thayer via Public
<public at cabforum.org> wrote:
> [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?

I'm not sure I follow.

Any change that a CA MUST incorporate will be the result of a Ballot,
absolutely. The Ballot will result in the publication of a new BRs
version (following the IP review period), the completion of which
makes the new version the effective version.

If I understand correctly (but probably not), your concerns relate to:

1) If, as a CA, I make a change before the Ballot is voted on, I
cannot update my system to reflect that (no Ballot == no BR version)
2) If, as a CA, I make a change after a Ballot is voted on, but before
the IP review period has completed, I cannot update my system to
reflect that (no published BR version / no assurance that the version
will pass through IP review)

Is that correct? If so, I don't think that changes, even if we ascribe
version numbers to sections, because the same timing issues would
arise. If it is a concern, it seems the likely proposed solution would
be to ensure we "don't reuse version numbers" (for sections or for the
CABF documents), but that seems good across the board?

If a new method is being permitted, which would otherwise be forbidden
by the current BRs, then you cannot use the new method anyways until
the completion of the Ballot and the IP review.
If a new method is being permitted, but is otherwise permitted by the
current BRs, then can't you simply record the current BR version of
when you performed the validation?

Apologies if I've completely missed your point, but I'm not sure I
understand the distinction between Ballots and BR versions, since only
BR versions are authoritative (having completed both Ballot stage and
IP review)

>
>     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.

I'm not sure I understand this remark. Surely you're paying attention
to the publication of new BR versions, which is done at the completion
of the IP review period for the Ballot, after the Ballot succeeded?

>     > 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 understand the remark that it provides no value?

It sounds like we're in agreement that CAs are, today, expected to
review every published BR version to ensure compliance. Recording the
BR version reflects an affirmative statement that such a review has
been completed, or otherwise reflects when the CA last reviewed that
particular validation or validation method.

>     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.

I'm not sure I understand this remark either. During the discussion
about less secure methods, at least one prominent member stated that
they do not maintain easily accessible records to be able to determine
whether or not they performed the validation securely or insecurely,
and thus were opposed to any restrictions to reduce the insecure
methods. They made this point several times, and while it may have
been that they communicated it ineffectively, certainly the conclusion
that folks came away with was that at least one member is not
maintaining their records in an easily accessible way. They indicated
it would require revalidating all of their information to determine if
it complied with the new requirements.

By clearly including this individual point - which itself is merely
recording the conclusion of what's already required to be logged as
part of the audit logging requirements - we hopefully get to a point
where this line of argument - that it's not reasonable to determine
how they validated a certificate/authorization domain name - is not
something that holds back reform to less secure methods.

> [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

Except sections like 4.2.1 can influence this process, which is why a
holistic view of the Baseline Requirements is needed. Similarly,
consider the recent forbidding of DTPs - had this been in place
beforehand, but only ascribed to the method, it would not be possible
to distinguish whether or not it was a 'DTP-less' validation. By
recording a 'post-no-DTP' version, it's clear that any validation was
directly done by the CA, and no DTPs (or reuse of DTPs) was performed.

Hopefully that provides enough rationale for why an entire version
number - which is what it would seem CAs should already be using -
would be used.