Given today’s SHA-1 news, how about we discuss moves to deploy SHA-3 as a fallback to SHA-2 instead?
> On Feb 23, 2017, at 9:39 PM, Ryan Sleevi via Public <[email protected]> > wrote: > > > > On Thu, Feb 23, 2017 at 5:23 PM, Kirk Hall via Public <[email protected] > <mailto:[email protected]>> wrote: > 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, CFCA, > GDCA > Browser: Apple > > The following members voted no/abstained, but included reasons outside of > this: > 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 achievable. > > 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. > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
