<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 30, 2020 at 12:42 AM Dimitris Zacharopoulos (HARICA) via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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"</div><div><br></div><div>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.</div><div><br></div><div>Put differently: If lifetimes were removed from SC31, then the conclusions from <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html">https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html</a> are just as relevant. If lifetimes are included in SC31, and it fails, the conclusions from <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html">https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html</a> 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. </div><div><br></div><div>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 <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html">https://archive.cabforum.org/pipermail/servercert-wg/2020-June/001997.html</a> 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>