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

[Ryan Sleevi]

On Tue, Apr 18, 2017 at 2:48 PM, Geoff Keating <geoffk at apple.com> wrote:

> I’m really not sure what the issue is here.  Microsoft sent their vote to
> the public mailing list before the deadline.  The message was posted on the
> public mailing list (by Kirk) in a reasonably timely manner.  I don’t see
> any conflict with the bylaws.
>

It's unclear if your "really not sure" reflects an uncertainty of the
concerns, or a disagreement with it. The Bylaws don't permit the process
you described.


> I agree it would have been better if the vote had appeared on the list at
> the time it was sent.
>
> I also see no point in litigating this.  If this ballot fails solely for
> this reason it will surely be submitted again and will pass.  In fact I
> would lobby for Apple to support the re-ballot instead of abstaining,
> purely to discourage rules lawyering.
>

I think if the result is that a subsequent Ballot was held, then the
concerns would be meaningfully addressed and the result would be
unambiguous and uncontested. Further, there would be no uncertainty that
our Bylaws, and the protections afforded by them, are meaningful, and the
ability of the Forum to self-regulate is not questioned. Surely that's a
clear and desirable goal, regardless of the position of rules lawyering.

I would suggest that had this not been a 'tiebreaker' vote, the concern
about accepting Microsoft's vote would not be an issue. The Forum, via the
Chair, has already demonstrated several times that it's willing to abide by
the timeliness of the votes, regardless of how well-intentioned the delayed
votes may be. The Forum has also demonstrated that it's willing to discard
votes in situations where multiple organizations represent the same Member
(in the Qihoo 360/WoSign/StartCom case). In these past cases, there was no
issue with discarding these votes that did not adhere to the bylaws,
because they did not have any meaningful impact on the result.

The issue we're presented now is whether we value our Bylaws - and the
protections afforded by them, for all members - over the results. A
position that suggests it's acceptable to accept this vote, because a
revote "will pass", suggests that the results are more important. And in
valuing such results, we undermine the protections, and thus undermine the
ability of members to participate and of the Forum to self-regulate.

The fact that Google voted "No" against this and that Microsoft voted "Yes"
is not the issue at play. The issue at play is whether or not we adhered to
our process for adoption.

Were it not for Section 2 of Ballot 194, which is entirely improper, if
other browser members, which use the Baseline Requirements and their audits
as part of their root program, agree with Ballot 194's goals, then it does
seem reasonable to incorporate into the BRs. I don't think anyone has
suggested the BRs represent the best security, or the necessary security,
just the minimum consistent among all browsers. If some browsers feel that
reuse of information is acceptable, and others do not, then it's perfectly
reasonable to suggest that it can be imposed as a root program requirement,
unless and until there is consensus that the security improvements are
worthwhile. This is no different than, for example, Mozilla requiring
disclosure of subordinate CAs (which the BRs do not require), or of Google
requiring Certificate Transparency for EV certficates (which the EVGs do
not require), or of Microsoft requiring disclosure of security incidents to
them and the ability to revoke certificates (with the BRs equally do not
require).

So I think Apple voting in favor of a reformed Ballot 194, excluding
Section 2, if it so agrees, would be fine. But let's not confuse the result
with the concerns about the process and the propriety of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170418/7ab8e41c/attachment-0003.html>