[Servercert-wg] Document Versioning

[Ryan Sleevi]

To be clear, we're going back and forth on the substance of your
objections, and that's continuing to make it difficult to meaningfully
resolve.

As I see it, from this thread, there's been two objections raised:

1) Objections over Process
2) Objections over Numbering

Process:
- This is objecting to the notion that Ballots can assign version numbers
*at all*, and a view that Ballots should not be assigning versions at all
(except for placeholders to be filled by the Chair)
- Forms of this include:
  - "This is how we've always done it"
  - "What if we have multiple ballots?"
  - "The Chair should be able to change the version number / tables at will"

Numbering:
- This is an objection over the specific numbers chosen
- Forms of this include:
  - "This wouldn't be an issue if the versions were sequential"
  - "What if someone chose a version 100"
  - "People will be confused by why there are gaps"

I have no regard for the Process objections, precisely because it's a
Ballot following our Bylaws, and it's right within the text of the thing
we're voting on. It's functionally part of the document itself, at present,
and if we want to change that, we need to change our Bylaws (and, likely,
our Charter) so that the Chair of the CWG can exercise version control of
the documents. While the exact color we paint that bikeshed can be deferred
until later, objecting to using a Ballot to change the text in a Final
Maintenance Guideline rings hollow, so let's just ignore those objections,
because I don't think we'll find consensus on the substance of objections.

With respect to Numbering, the choice was not random. Browser Root Programs
are seeing, routinely, CAs fail to annually update their CP/CPS, or, when
they do, failing to detect that there are meaningful changes. Our numbering
here has attempted to adopt a semantic versioning style (Major, Minor,
Patch) approach, as used in Software and some other standards documents,
but never actually defined those semantics. What ended up being practiced
is a "Count to 10, then wrap around" - for no real reason, other than
perhaps that's what the Chair felt.

Previously, the Forum had discussed (with Ballot 146) using a meaningful
version - which is why it jumped from 1.2.5 to 1.3.0, to signal "Oh, hey,
there's big changes". The discussion then was to look at a "2.0.0" if/when
the Net Sec, EVGs, and BRs were folded into a unified CP/CPS, but that
never materialized.

If we want to talk about _why_ the numbers were chosen, and _why_ they're
strictly better than the monotonically increasing number being used here,
the rationale chosen was "This is removing something previously permitted"
- i.e. a breaking change - and that's exactly the kind of thing you'd want
to signal with a version number. When we add things; say, adding an LEI
identifier (as proposed by Tim recently), that doesn't require CAs to go
and change any existing processes. On the other hand, changing the maximum
age for the certificates and validity does affect existing deployments: the
kind of thing that's extremely useful to signal with a major version bump.

My hope, in forcing this gap, was to be a very clear signal that "Yes,
things have changed, pay attention". The downside (of CAs wondering why
there's a gap) is an *upside*, in the hope that it addresses some of the
real issues we as Root Programs are seeing with CAs following things. It
also helps make it clearer, when looking at Audit Criteria, "just how
recent" things are.

Do we need to use a (Major, Minor, Patch) numbering scheme? Of course not.
We could have said "The BRs as adopted on 2019-09-09", for example, using a
date-based scheme that perhaps achieves the above objective even better.
The numbers don't really matter, we've never defined a purpose or
structure, but what we do know is that things aren't going as well as they
could, and there's a real need and opportunity to improve things.

Now, if CAs are going to vote against the Ballot on the basis of the number
- and I wholly admit, this ballot "conveniently" gives them the excuse to
suggest that they're voting against it not because of the dates, but
because they don't like the numbers - then that's disappointing, but at
least it's clear what their priorities are, and that's useful for the
ecosystem. If folks feel that adopting "1.8.0" is somehow going to doom the
Forum or the Servercert WG into a life of reprobate versioning in which up
is down, day is night, and cats and dogs live in harmony, then as laughable
as that is, we still have time to change. But we should really be carefully
thinking about what the substance of the objection is, and why it's there.
And, perhaps more importantly, what folks feel is the "right" solution for
CAs and the ecosystem not being aware that things are meaningfully
changing, and what once was allowed, is now no longer.

The Validation WG took exactly the same approach I proposed here with
Ballot SC22 when they decided to remove and renumber 3.2.2.4 methods: to
make it clear to CAs and Relying Parties that Things Have Changed. I'd be
dismayed if now we say that's not good, but at least it's clear that's what
we're saying.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190821/f21547dc/attachment.html>