“it would seem like February 23, 2018 is achievable”, I think one-year time to prepare for everything (technical, system, marketing, contract etc.) is enough, at least for WoSign.
Best Regards, Richard From: Public [mailto:[email protected]] On Behalf Of Ryan Sleevi via Public Sent: Friday, February 24, 2017 10:39 AM To: CA/Browser Forum Public Discussion List <[email protected]> Cc: Ryan Sleevi <[email protected]> Subject: [cabfpub] Ballot 185 - Next steps 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
