<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I think you are overstating the consensus on the idea that “revocation checking doesn’t work.”  Which relying parties have said that?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">And much of your justification for the changes you want to make on certificate lifetime are based on that conclusion.  But many disagree with that conclusion, and if we’re
 going to work on ways to deal with certificate revocation, then a renewed push for revocation checking is something we should also be discussing.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Here is the conclusion from a well-respected 2015 academic study from Stanford measuring browser revocation checking.  The study even included suggestions on how to improve
 CRLSets that could “</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">could increase their coverage by several orders of magnitude”.  Is Google willing to work on these issues as well?  We are all in this together – CAs and browsers –
 in improving user security.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">An End-to-End Measurement of Certificate Revocation in the Web’s PKI.</span></i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> 
<a href="https://web.stanford.edu/~aschulm/docs/imc15-revocation.pdf">https://web.stanford.edu/~aschulm/docs/imc15-revocation.pdf</a></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.25in;line-height:115%"><span style="font-size:11.0pt;line-height:115%;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;text-autospace:none"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">“*** CONCLUDING DISCUSSION<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;text-autospace:none"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;text-autospace:none"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">“Certificate revocation is a necessary component of any PKI, but it comes with costs, both real and perceived: CAs carry the cost
 of disseminating revocation information, while browsers risk the cost of increased web page load times. In the trade-off between low communication overheads and security, both ends of certificate revocation (those who issue and those who fetch) are naturally
 tempted towards the former. Indeed, the very utility of revocations has been debated and doubted [citation omitted] by the security community, but to date, these debates have had to largely depend on anecdotal CA and browser behavior.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;text-autospace:none"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;text-autospace:none"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">“We have presented in this paper an empirical measurement of the options at all parties' disposal - website administrators, CAs,
 and browsers - in terms of the communication overhead costs they impose and the extent to which they are currently being employed.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;text-autospace:none"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;text-autospace:none"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">“Overall, our results show that, in today's Web's PKI,
<u>there is extensive inaction with respect to certificate revocation. While many certificates are revoked (over 8% of fresh certificates and almost 1% of alive certificates), many web browsers either fail to check certificate revocation information or soft-fail
 by accepting a certificate if revocation information is unavailable</u>.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;text-autospace:none"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;text-autospace:none"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">“On the positive side, our results also demonstrate that there are several clear paths to improvement. To reduce CRL sizes, CAs
 can simply maintain more, smaller CRLs (in the extreme, each certificate could be assigned a unique CRL, resulting in an approximation of OCSP) - surprisingly few CAs currently take such an approach [citation omitted] and therefore incur greater bandwidth
 costs than strictly necessary. A promising improvement is OCSP Stapling, as it reduces CA bandwidth costs as well as web page load times - yet, not all browsers support it, and some that do simply ignore the responses. A more pervasive deployment of OCSP Stapling,
 at both websites and browsers, could lead to an immediate improvement in user security at little additional performance cost, particularly if the Multiple OCSP Staple Extension [citation omitted] were adopted to allow intermediate certificates to be stapled.
 Finally, we show that a straightforward modification to CRLSets could increase their coverage by several orders of magnitude.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in;text-autospace:none"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">“From these results,
<u>we conclude that certificate revocation ought not be given up on - that indeed it serves a critical yet overlooked role that, with proper support from all parties, can be achieved at a cost far outweighed by the benefits</u>. To realize this, we believe
 continued measurement and validation of future browsers will be of utmost importance, and to this end have made our data and our browser test suite publicly available at
<a href="http://www.sslresearch.org">http://www.sslresearch.org</a>.” [Emphasis supplied.]<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ryan Sleevi [mailto:sleevi@google.com]
<br>
<b>Sent:</b> Friday, February 3, 2017 1:11 PM<br>
<b>To:</b> CA/Browser Forum Public Discussion List <public@cabforum.org><br>
<b>Cc:</b> Kirk Hall <Kirk.Hall@entrustdatacard.com><br>
<b>Subject:</b> Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Kirk,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While I understand you have a different view of how browsers should work, I think it might be more useful and productive to this discussion to acknowledge that browsers (and to the broader extent, relying parties) have disagreed your premise
 - and more generally, security practitioners outside of the Antivirus Industry (in particular) recognize your approach to security as flawed.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">However useful this discussion, though, it might be more useful if CAs could focus on specific reasons or challenges that the ballot would impose, particularly considering the (many) benefits I outlined in my reply to Doug.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Concretely, I think there's an onus on CAs to show that these (considerable and meaningful) benefits are somehow overshadowed by the cost. To date, we've yet to see any evidence or counter-point that somehow users would be _less_ secure
 with the proposal.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Feb 3, 2017 at 12:07 PM, Kirk Hall via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Richard, I’ve always thought that if revocation checking worked in (say) 85% of OCSP or CRL queries
 and revealed to users that a bad cert had been revoked and a site should not be trusted, then we (CAs and browsers) were successfully protecting 85% of users who were visiting the bad site.  To me, that is a huge win.  If we can work to improve that figure
 to 98% or 99.9% over time or with new methods, even better.  But warning 85% of users of a revoked cert today is way better than warning 0% of users of a revoked cert as happens today when browsers don’t even bother checking for revocation.  (It’s like a highway
 commission saying “This guardrail won’t prevent 100% of accidents, so we won’t put up a guardrail at all” – if the guardrail stops 99% of accidents, it’s a good thing.)</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If browsers always tell relying parties “Revocation checking doesn’t work”, then I guess that’s what
 relying parties will tend to believe over time – so no use asking what relying parties believe .  But if revocation checking works in the great majority of cases where it’s tried, then it is a major tool for user security that should be restored by browsers.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">(And let’s not raise the issue “revocation checking can be blocked in a compromised environment, MITM,
 etc. so it’s never even worth trying in any environment” – that an extremely weak argument for giving up all revocation checking in the normal internet environment that the vast majority of users encounter, where revocation checking is not blocked and users
 can receive warnings of a revoked certificate.)</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Public [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Richard Barnes via Public<br>
<b>Sent:</b> Friday, February 3, 2017 11:41 AM<br>
<b>To:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br>
<b>Cc:</b> Richard Barnes <<a href="mailto:rbarnes@mozilla.com" target="_blank">rbarnes@mozilla.com</a>><br>
<b>Subject:</b> Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">Is there anyone on the relying party side of the universe that believes revocation works?  Even among browsers that send OCSP requests, none of them hard-fail if it doesn't work, because
 in practice, OCSP servers are so awful that HTTPS would become unusable.  So OCSP is still, as AGL says, a seat belt that breaks when you crash.  Seems fair to call that broken.<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Even if OCSP were magically to become usable, though, (or some replacement for it) this ballot would still be necessary for all the other reasons that have been discussed here.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Fri, Feb 3, 2017 at 11:34 AM, Rich Smith via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Ryan, since you're using your age old FUD "revocation doesn't work" (because certain browsers have chosen not to consult revocation information) as part of the reasoning as to why
 this ballot is necessary, I think it's quite germane to the discussion.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On 2/3/2017 11:38 AM, Ryan Sleevi via Public wrote:<o:p></o:p></p>
</div>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Fri, Feb 3, 2017 at 9:11 AM, Rob Stradling <<a href="mailto:rob.stradling@comodo.com" target="_blank">rob.stradling@comodo.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Ryan, what targets (filesize/performance/reliability/reachability/etc) would CAs need to meet before it would become viable to reintroduce CRLs to the WebPKI (i.e., for Chrome to
 start checking CRLs and hard-failing if they're unobtainable)?<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Happy to have that discussion at another time, but it's not germane to the discussion at hand, as I clearly indicated in the original message. It's necessary, but not sufficient,
 to have that, and we're not presently proposing addressing all the other necessary conditions. Baby steps.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> <o:p></o:p></p>
</div>
</div>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Public mailing list<o:p></o:p></pre>
<pre><a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><o:p></o:p></pre>
<pre><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>