[Servercert-wg] Ballot SC31 - Browser Alignment

[Ryan Sleevi]

On Tue, Jun 30, 2020 at 12:42 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg <servercert-wg at cabforum.org> wrote:

> IMHO, we've had "big ballots" before, like SC31, that try to deal with
> many issues at once and in such cases there is always a risk of finding a
> single controversial issue that may cause the entire ballot to fail. It
> seems that the 398-days issue creates such a risk and it's up to the
> proposer and endorsers to weight in this risk. In most cases I can
> remember, proposers that faced such a challenge, separated the
> controversial issue into a separate ballot so that the Forum/WG can make
> forward progress with the majority of the "big ballot". In fact, this was
> one of the first things I learned in the Forum when I started actively
> participating and contributing to ballots. This advice came from Ryan
> Sleevi and it made perfect sense to me.
>

As noted, the only objection here is not an objection on merit or content,
but one of principle, and that principle is unfounded. The objection
specifically made by Chris Bailey of Entrust, and seconded by Doug Beatie
of GlobalSign, is not one to suggest that were the "objectionable" portion
removed, there might be anything useful accomplished through such
separation. Indeed, any separation of lifetimes into their own ballot would
have no meaningful effect on Root Programs, which have already implemented
this requirement, no different than the removal of any other portion of
SC31 would have no effect on any of the other existing root program
requirements.

The question of where the burden of proof rests is a misdirection, in that
it's really just symptomatic of the same debate over principle and not
substance. It could be highlighted that the objections raised during SC22
have, in many ways, lost their relevance by virtue of time and evangelism.
The same problematic approaches with the data CAs shared during the SC22
discussion is still being brought forward, so it seems we've made no
progress with CAs there. CAs haven't met any burden of proof to consider
otherwise. Indeed, the only suggestions, as highlighted by Doug and echoed
in spirit by Daniela, while appearing substantive, are just variations of
the same principle we've been debating this whole time.

It would seem that the only principle guiding any of the discussion or
concerns raised by those vocally opposed to SC31 in this thread is an
objection that predates the Bylaws itself, and is about the unequal nature
of the Forum. This asymmetric nature of the Forum is by virtue of the fact
that Browsers are the customers of CAs, no different than any customer
relationship, and have a vested interest in the service they receive from
CAs. CAs would prefer to dictate the terms on browsers, much like a grocery
store might want to dictate terms on its customers that might say "We'll
sell you a liter of milk, but only if you buy 80 kilos of rice or if you
agree to our Milk by the Minute Subscription Plan, and only if it's on a
Tuesday and you're wearing a clown nose"  while ignoring that browsers most
likely response is "OK, I just need a liter of milk, so I'll just go
somewhere else"

The particular change CAs are objecting to, with respect to lifetimes, is
identical to every other change that is part of SC31. It is a change that
aligns with one or more Root Programs, which have already implemented these
requirements or committed to doing so. Removing that from SC31 does nothing
to improve or alter that, and the concerns for additional documentation
have already been repeatedly addressed in good faith, but dismissed. The
discussion had so far does highlight that if lifetimes were removed, it
might be/inevitably will be interpreted by some CAs as somehow legitimizing
the view that its omission meaningfully alters root programs or that
browser needs are been met.

Put differently: If lifetimes were removed from SC31, then the conclusions
from
https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html are
just as relevant. If lifetimes are included in SC31, and it fails, the
conclusions from
https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html
hold.
There is no outcome, except that of SC31 succeeding, in which the Forum is
able to demonstrate that it provides a valuable and useful venue for
further collaboration. Clint's questions get to the heart of that, and why
the consternation over SC31 has the only effect of devaluing and
delegitimizing the Forum.

I know this seems like an extreme view, but we're nearly 10 years in on the
same debate, at some point, browsers and surely CAs have to recognize sunk
cost fallacy. Appealing to the Bylaws doesn't resolve those questions from
Clint, or the outcomes and concerns I highlighted, it simply ignores and
dismisses them. Equally, it's unfortunate that you'd wear the Chair Hat
while offering your own personal, and unfortunately, inaccurate view of
audits, particularly when they're so clearly dismissive of these concerns.
It only reinforces why the paths outlined in
https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html are
most likely the best path forward, given that in the near decade that this
debate has been going on, little has changed. At the end of the day, there
are finite resources available to protect users, and it's important to make
sure those resources are well spent on the things that matter. Lifetimes
matter, perhaps more than anything else in the Forum outside of SHA-1, and
so that change will happen, is happening, and has happened. The same debate
about the relevance of the Forum, nearly 10 years on? That... is not time
well spent when there's clearly little to show for it.

SHA-1 is apt: consider how much time was spent on the transition, which
despite years of good faith efforts, CAs were still arguing to allow, up
until the literal day they were shown it was comprehensively broken at
readily affordable, easily achieved computation costs. Was the time spent
in the Forum, working with CAs, time well spent, considering the
deprecation ultimately happened because Root Programs took action when CAs
were unwilling or unable to? Objectively, no, it was not time well spent,
and users were not made better through the ultimately pointless debates.

If anything, SC31 itself can be argued as serving as the Ballot you
suggested. Any failure of SC31 demonstrates that any further efforts to
reform the Forum to better provide a more relevant and useful service to
browsers are doomed, on principle. If that happens, then as CAs have
explicitly suggested, browsers are better off going outside of the Forum
and ceasing to invest effort within the Forum. And so if SC31 fails, it's
very useful feedback, because that's a clear and unambiguous signal as to
the next steps. If SC31 succeeds, then we probably need a Ballot to
recharter the SCWG, which could either succeed ("yay, the Forum is still
relevant") or fail ("yay, we have a clear signal that the Forum can't meet
our growing needs"), but at significant cost for seemingly little value. It
may be that the cheapest, and best, answer is exactly what some CAs have
proposed: for root programs to cut their losses, independent of SC31, and
ignore the Forum entirely going forward.

As much as it might seem upsetting for some CAs, the Forum's relevance
isn't defined by its Bylaws, the Forum's relevance is directly coupled with
how well the one service it produces, a set of documents that can be used
to develop audit standards and criteria that browsers can use and that
actually meet browser needs. Plenty of SDOs, particularly the most
successful SDOs for the Internet, the W3C and the IETF, had had to grapple
with this seeming conflict: the value of a standard is not intrinsic, it's
whether or not it meets a need.

When a standard fails to meet the needs of those who would use it, it fails
to be relevant, and the SDO itself fails in its mission. If an SDO fails to
produce relevant standards, the SDO becomes irrelevant. For many folks in
the Forum, where this might be their first SDO or standards-setting
experience, or where "standards" are produced through special status
without having to compete in the market because they're imposed externally,
these realities are not something they've grappled with before, and this
can be a very terrifying concept to accept. However, this is an opportunity
to rise to the challenge, not shirk from it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200630/2876b119/attachment-0001.html>