[cabfpub] [EXTERNAL]Re: ]RE: Ballot 194 - Effective Date of Ballot 193 Provisions is in the VOTING period (ends April 16)

[Ryan Sleevi]

On Mon, Apr 17, 2017 at 2:47 PM, Dean Coclin <Dean_Coclin at symantec.com>
wrote:

> “Unless it can be demonstrated that this message was received by all
> participants subscribed, and was able to be crawled and index by an
> Internet search engine, I do not believe you can argue that the "posting"
> requirement has been met. We must look at the entirity of the Bylaws, and
> choosing this particular interpretation is not consistent.”
>
>
>
>
>
> I think this is the crux of the matter at hand. There are different
> interpretations of “posting” and interpreting it one way or the other is
> the cause of the issue. Looking at “entirety” is one way. Looking at
> “intent” is another.
>
>
> I remember a time when we did not have public voting. Then a change was
> made, with the intent being to inject transparency into the voting process
> and publicly disclose where CAs and Browsers came down on issues. It would
> seem this intent is satisfied by the chair’s disclosure of the votes online.
>

We discussed this during the adoption of public voting and the public mail
list, however. That is, in the conversations leading up to that, there was
the discussion about whether to have 'secret ballot' approaches (all votes
sent to Chair) or whether to have on-list public votes, with the conclusion
being the latter.

To ensure all members understand the history related to these changes:
Ballot 73 - https://cabforum.org/2012/05/11/ballot-73-public-mail-list/ -
introduced the public mailing list
Ballot 79 - https://cabforum.org/2012/07/25/ballot-79-mailing-list-usage/ -
introduced the deference to do things publicly
Ballot 98 - https://cabforum.org/2013/02/22/ballot-98-public-voting/ -
required that all voting happen on the public list


> I’m not arguing either way, just pointing out the viewpoints.
>
>
>
> So what are the possible solutions?:
>
> 1.       Do not count Microsoft’s vote. The ballot then fails. I’m
> guessing the proponents will post a new ballot stating the same thing and
> is voted on again. The bylaw ambiguity should be clarified in a different
> ballot.
>
> 2.       Count Microsoft’s vote. The ballot passes. Clarify the bylaw
> ambiguity in a new ballot.
>
>
>
> These are really the only possible ways forward under our bylaws. The
> Chair and Vice-Chair can’t be asked to make a ruling since they could be
> biased one way or the other on the outcome.
>

Thanks for stating that Dean, because that really is the crux of the
matter. I agree with you that neither the Chair nor the Vice-Chair can or
should be asked to serve as "tie-breakers" or "interpreters at large" of
the Bylaws. They exist to facilitate and honor the Bylaws, but not to offer
their interpretation in a privileged place beyond that of any other member.
Thus, to decide #2 - whether to count Microsoft's vote - the process is
what we do for all such matters, which is the formalization of a Ballot.
We've done Ballots like this in the past, without touching on documents, as
reflected in Ballot 77 -
https://cabforum.org/2012/06/07/ballot-77-emergency-extension-of-ipr-requirements/
- and the (failed) Ballot 82 -
https://cabforum.org/2012/07/31/ballot-82-extend-ipr-introduction-timetable/

When it came to deciding process, we've used Ballots such as Ballot 85 -
https://cabforum.org/2012/08/24/ballot-85-governance-reform/ - to define a
process and reflect members agreement on that process. Most notably, it
spells out an agreement first and foremost that the process was correct,
and then, and only then, did it proceed to executing that process. This was
done to ensure there was consensus on the process.

>From this perspective, if we were to accept Microsoft's vote, it raises the
question about whether the Ballot is retroactively changing the Bylaws (if
it succeeds). This is understandably troubling, as discussed during Ballots
180 - 182, as it suggests our bylaws are flexible to the point that
retroactive IP risk may be introduced for members. This is part of why we
so strongly objected to the approach the Chair used with respect to
interpreting the execution of these Ballots, and why we supported the
further clarifications in Ballot 183 as a necessary condition before
introducing any further ballots using such an ad-hoc and unsupported
approach.

Thus, it argues that Option 1 is the correct, unambiguous, and with
precedent approach to resolve this issue. If this Ballot succeeds on its
merits, it's clear that there's not agreement that the current language
represents the Baseline of security, and that's perfectly fine and
appropriate, and allows for other members to appropriately reflect that
within their policies, should they so wish. This may be the most desirable
outcome for everyone regardless, and so it seems entirely reasonable and
appropriate to go forward on that.

Regarding the "Section 2" of the Ballot, the outcome of Ballot 194 in no
way changes how the Baseline Requirements applies to new certificate
issuance, so there is no additional 'risk' in conducting this second
ballot, because as highlighted before, there is no legitimate way a CA can
continue to issue such certificates without violating the Baseline
Requirements. This only changes that discussion from being several weeks to
being closer to two months, but that remains the prerogative of root
programs to accept or reject such qualifications, as it always has.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170417/21bf2fbb/attachment-0003.html>