<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 11:51 AM, Dean Coclin <span dir="ltr"><<a href="mailto:Dean_Coclin@symantec.com" target="_blank">Dean_Coclin@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_-2731447652314419171WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">Building consensus in meetings is different than building consensus for a ballot. Discussions happen in meetings without concrete proposals, as was shown in the
 chart I posted earlier from the Zurich meeting. I can’t recall anyone coming out before this ballot seeking consensus for a 1 year validity effective in 4 months.  So yes, I do think that now that a formal proposal (ballot) has been issued, a serious attempt
 to build consensus should be undertaken. This will likely take more than 2 weeks of online back and forth. We have a F2F coming up in 40 days, giving folks time to reach out and get more input.  I do believe that everyone wants to improve security but as the
 scattering of input shows, this must be balanced with the user constituency needs which really haven’t been fully vetted for THIS particular proposal. You’re right, I’m not saying we can reach consensus on this ballot but perhaps an alternative compromise
 can be reached which balances the needs of all constituencies.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">Regarding the motive, all I’m saying is that there is no consensus, therefore, it seems a ballot failure is a foregone conclusion and you must know that, but
 you want it to go forward anyway.  Call me crazy?</span></p></div></div></blockquote><div><br></div><div>We had a number of concrete proposals. It was clear there was no consensus that any one of them would work for everyone, that part was clear.</div><div><br></div><div>However, we also know it doesn't have to work for everyone, it has to work for enough of them. And as we discussed - and discussed and discussed - regarding the ways in which to structure Ballot 183 - we also know that unless and until faced with a binding vote, it can be incredibly difficult to measure consensus and process.</div><div><br></div><div>So I put forward a ballot that represents the absolute maximum acceptable validity period we're willing to consider at this time, given the three years of information that CAs have shared, the concerns raised, and the challenges that have arisen in the ecosystem in that time. If CAs have information that they haven't shared, despite knowing this was an important matter of concern - and despite the practical evidence of this - well, that's unfortunate for those CAs' customers that their CA does not consult with them or represent their views in an actionable way.</div><div><br></div><div>Further, since it's quite clear - again, from our three years of meetings - that no proposal so far, short of _extending_ validity periods (which is outright unacceptable) - had the necessary consensus for success, there's also value in understanding how other Root Stores / Application Software Suppliers feel about the security risks of CA practices.</div><div><br></div><div>I think it's important to realize that the "Baseline Requirements" is simply the minimum set of common standards. It does not, in any way, represent industry consensus on *best* practice, merely consensus on *minimum* practice.</div><div><br></div><div>It's possible that this ASS is the only ASS that feels that, when faced with ecosystem challenges, such as multi-year misissuance issues <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ">https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ</a> ( based on current information, absent a reply to <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/KrDBAoDNDgAJ">https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/KrDBAoDNDgAJ</a> ), that an acceptable way to minimize risk to our users is to reduce validity periods.</div><div>It may be that this ASS is the only ASS that is concerned that 39 months to fix issues like <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/zsBB_XqdOCg/CZCQnnOcDAAJ">https://groups.google.com/d/msg/mozilla.dev.security.policy/zsBB_XqdOCg/CZCQnnOcDAAJ</a> is too long.</div><div>It may be that this ASS is the only ASS concerned that more CAs than one may have issues similar to <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/Htujoyq-pO8/uRBcS2TmBQAJ">https://groups.google.com/d/msg/mozilla.dev.security.policy/Htujoyq-pO8/uRBcS2TmBQAJ</a> , and that, given the possibility of future issues like that, we should strive to limit validity so that we can reduce the risk in the period from detection to remediation.</div><div>It might be that this ASS is the only ASS who is deeply concerned about the reliability of CAs to detect and respond to misissuance, given issues like <a href="https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html">https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html</a></div><div>It might be that this ASS is the only ASS who is deeply concerned about the ecosystem and the impact to relying parties when steps such as <a href="https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html">https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html</a> are necessary, and how to minimize disruption to as many parties as possible.</div><div><br></div><div>Perhaps that's because other Root Stores / Browsers have different concerns than this ASS. And if so, it's good to know.</div><div><br></div><div>However, as the Forum affords a public and transparent venue to judge the reaction and consensus among Browser vendors, and as we know, Ballots are the effective way to get opinions on the record, particularly when potentially binding, it helps to measure the zietgeist in a way far more effectively. It also effectively avoids the many troublesome issues that CAs have no doubt considered before forming the "CA Security Council," and which hopefully they're paying close attention to avoiding.</div><div><br></div><div>By having this discussion - with a concrete ballot - we can effectively measure consensus, and know whether CAs are committed to security. We can understand if ASSes are being unreasonable, by encouraging CAs to concretely articulate objections that can be responded to or addressed, rather than vague statements or empirically flawed surveys. And we can better understand what impact, if any, would happen if ASSes needed to expressly limit the validity period of certificates via root policy, if consensus cannot be reached.</div><div><br></div><div>But I do want to emphasize again and again - the Baseline Requirements represent just that - the baseline, not the best practice. As we ASSes consider how to best protect our users, it's important to realize we strive to do more than the bare minimum for protecting our users.</div></div></div></div>