[cabfpub] Ballot 185 - Next steps

Ryan Sleevi sleevi at google.com
Fri Feb 24 02:39:06 UTC 2017

On Thu, Feb 23, 2017 at 5:23 PM, Kirk Hall via Public <public at cabforum.org>

> Results on Ballot 185
> The voting period for Ballot 185 has ended.  Here are the results.
> *Voting by CAs – 25 votes total plus abstentions*
> 1 Yes vote: Let’s Encrypt
> 24 No votes: DigiCert, Entrust, AS Sertifitseerimiskeskus, Izenpe, ANF
> Autoridad de Certificación, Comodo, Certinomis, HARICA, GlobalSign, Quo
> Vadis, GoDaddy, Actalis, Symantec, Trustwave, CFCA, Secom, TWCA, GDCA,
> Certum, OATI, Buypass, SHECA, CNNIC, Cisco
> 3 Abstain: Logius PKI, SwissSign, Chunghwa Telecom
> 4% of CAs voted in favor
> *Voting by browsers – 4 votes total plus abstentions*
> 2 Yes votes: Google, Mozilla
> 2 No votes: Microsoft, Qihoo 360
> 1 Abstain: Apple
> 50% of browsers voted in favor
> Under Bylaw 2.2(g), a ballot result will be considered valid only when
> more than half of the number of currently active Members has participated.
> Half of currently active Members is 10, so quorum was 11 votes – quorum was
> met.
> Bylaw 2.2(f) requires a yes vote by two-thirds of CA votes and
> 50%-plus-one browser votes for approval.  This requirement was not met for
> either CAs or browsers.  At least one CA Member and one browser Member must
> vote in favor of a ballot for the ballot to be adopted.  This requirement
> was met
> Accordingly, the ballot fails.

Thanks for posting this, Kirk.

As the Ballot Proposer, and as a Browser, trying to determine the next
appropriate steps and the actionable feedback from members who helpfully
contributed to better understanding their concerns, here's the summary of
the positions that I compiled, to better determine where there is
opportunity for consensus.

My hope is that, now having a concrete Ballot behind us, and an upcoming
meeting, we can use this opportunity to focus on the concrete concerns
raised, to recognize our opportunities to gather and share data in advance
of those discussions, to find commonality in our perspectives now that we
have a clearer picture of where people are approaching from, avoid
ratholing ourselves onto concerns that weren't raised as part of this
process, and hopefully, ideally, acknowledge the unacceptability of the
status quo, and the urgent need for a plan forward.

Given our own deep concerns about the CA ecosystem's current practices, I
anticipate Chrome will need to finalize our plans soon. My ideal outcome is
that we can use this time leading up to and during our meeting to explore
opportunities to reach an industry consensus, so that we can take this step
forward towards a more secure Internet together.

The following members voted no/abstained, but offered no suggestions on how
to improve or balance the concerns raised by members during the vote:
CA: AS Sertifitseerimiskekus, ANF Autoridad de Certificación,
Comodo, Certinomis, GlobalSign, Secom Trust Systems, TWCA, Certum, Buypass,
CNNIC, Logius, SwissSign, Chunghwa Telecom
Browser: Qihoo 360

The following members voted no/abstained, on the basis of the duration
afforded before this requirement became effective (6 months)
CA: GoDaddy, Actalis, Symantec, Trustwave, SHECA, Cisco, CFCA, GDCA
Browser: Microsoft, Apple

The following members voted no/abstained, on the basis of the validity
period for certificates (13 months) being unacceptably short:
CA: DigiCert, Entrust, Izenpe, Quo Vadis, Actalis, Symantec, Trustwave,
Browser: Apple

The following members voted no/abstained, but included reasons outside of
CA: Harica, OATI

For AS Sertifitseerimiskekus, ANF, Comodo, Certinomis, GlobalSign, Secom,
TWCA, Certum, Buypass, CNNIC, Logius, SwissSign, Chunghwa Telecom, without
having articulated your concerns on the Ballot, it's impossible to find a
solution that will work for y'all. I do want to encourage that future
ballots make use of the discussion period and voting to make it clear the
positions and concerns, so that Forum members can take the considerations
and find room for compromise, rather than simply obstructing progress.

For GoDaddy, Actalis, Symantec, Trustwave, SHECA, Cisco, CFCA, GDCA,
Microsoft, and Apple - is it a fair summary to suggest that if more time
was afforded to phase this in, appropriately evangelize to the ecosystem,
and change systems, this would be acceptable? Based on the feedback shared
so far, it would seem like February 23, 2018 is achievable, but it would be
useful to understand concrete feedback as to whether that's not the case.

For DigiCert, Entrust, Izenpe, Quovadis, Actalis, Symantec, Trustwave,
CFCA, GDCA, and Apple - I'm not sure we will be able to find consensus at
27 months, unfortunately. Ultimately, the acceptable validity period of a
certificate that a browser accepts defines its commitment to the Web
Platform that we will make every effort to avoid disrupting site operators
and users. In doing so, we browsers take on the liability that results from
CA misissuance, in that it becomes necessary for browsers to address issues
of CA incompetence, malice, and apathy in a way to minimize disruption to
our users while ensuring their security. Similarly, it represents how long
the browser views the data and methods used to be acceptable and
trustworthy relative to the security goals and requirements of the
browsers. While I appreciate the feedback, I suspect this is a point of
irreconcilable difference - 27 months represents a fundamentally
unacceptably long time, particularly given the risks the ecosystem faces
and the changes the ecosystem needs to cope with the continual violations
of the Baseline Requirements.

Given that some advocates of 27 months highlighted the concern that they
believed that automation was required, but not yet developed, or that it
would affect staffing plans, budgets, or contracts, my hope is that we
might be able to address those concerns motivating some to vote for 27
months by allowing more time for the ecosystem to adjust, such as exploring
what specific concerns would prevent February 23, 2018 from being

However, if the belief is that 13 months is unacceptably short, then we
must simply agree to disagree.

I realize that some members suggested a phased approach. Unfortunately, I
believe we have sufficient data at this point to know a phased approach
either represents a much longer delay in providing meaningful improvements
(as each phase needs transition time) or represents introducing significant
more confusion and ambiguity. That is, we know from past discussions - and
experiences such as internal server names, 120mo->60mo->39mo, or arguably
SHA-1 (issuance vs browser acceptance) - that such phrases tend to result
in incomplete migrations and preparations, and incomplete information about
the direction things are going.

Given that 13 months is the only realistically achievable goal in the
short-term (though I will state that we believe that 90-180 day should
represent the long-term goal, but for future discussion with much longer
phase in), and is the only acceptable goal, my hope is that by providing
more opportunity for phase in, we can avoid the intermediate step and the
pain and delays that go with it.

For OATI and Harica, I appreciate and value the thoughtful contributions
and suggestions you made. For OATI, my hope is that we can meaningfully
address your concerns by addressing and clarifying the scope of the
Baseline Requirements, and that by better understanding the concerns with
client certificates, we can remedy them and see your future support for a
new ballot. For Harica, I appreciate your suggestion of waiting for more
feedback. Unfortunately, I believe that given the three years of discussion
this matter has taken, it's unlikely that this will be actionable. Further,
given the above explanation of concerns, I do believe it may misunderstand
or undervalue the concern that some browsers may feel about accurately
representing a view of security and stability to end users / relying
parties, by over-valuing the concerns of site operators.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170223/7a928991/attachment-0002.html>

More information about the Public mailing list