<div dir="ltr">I would have trouble supporting that ballot.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 12, 2014 at 5:36 PM, Ben Wilson <span dir="ltr"><<a href="mailto:ben@digicert.com" target="_blank">ben@digicert.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">After discussions earlier today with Doug, here is where I think we were:<u></u><u></u></span></p>
<h2>9.8 Signature Algorithms<u></u><u></u></h2><p class="MsoNormal"><span>Effective as of January 1, 2015, the maximum validity of a Subscriber Certificate signed with SHA-1 shall be 15 months, unless the CA documents that the Subscriber Certificate (and corresponding CRL or OCSP response) is for a system or software that:<u></u><u></u></span></p>
<p class="MsoNormal"><span>(a) is used by either the Applicant or a substantial number of Relying Parties;<u></u><u></u></span></p><p class="MsoNormal"><span>(b) will fail to operate if the Certificate, OCSP Response, or CRL is not signed with the SHA-1 algorithm; <u></u><u></u></span></p>
<p class="MsoNormal"><span>(c) does not contain known security risks to Relying Parties; and<u></u><u></u></span></p><p class="MsoNormal"><span>(d) is difficult to patch or replace without substantial economic outlay.<u></u><u></u></span></p>
<p class="MsoNormal"><span>Effective as of January 1, 2016, CAs SHALL sign all Subscriber Certificates using one of the following algorithms: SHA-256, SHA-384, SHA-512, P-256, P-384, P-521, DSA 2048 (with prime q of 224 or 256 bits), or DSA 3072 (with prime q of 256 bits). A CA MAY use the SHA-1 algorithm to sign Subscriber Certificates (including for re-keys, renewals, and corresponding CRLs or OCSP responses) beyond January 1, 2016, provided that the CA has documented that the system or software meet the four criteria above.<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Ryan Sleevi<br>
<b>Sent:</b> Wednesday, March 12, 2014 5:46 PM<br><b>To:</b> Eddy Nigg (StartCom Ltd.)</span></p><div class=""><br><b>Cc:</b> CABFPub<br><b>Subject:</b> Re: [cabfpub] SHA1 Deprecation Ballot<u></u><u></u></div><p></p><p class="MsoNormal">
<u></u> <u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p><div><p class="MsoNormal">On Wed, Mar 12, 2014 at 4:36 PM, Eddy Nigg (StartCom Ltd.) <<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>> wrote:<u></u><u></u></p>
<div><div class="h5"><div><p class="MsoNormal"><br>On 03/12/2014 02:51 PM, From Doug Beattie: <u></u><u></u></p><div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">So, at this time, I’m in favor of:</span><u></u><u></u></p><p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-</span><span style="font-size:7.0pt;color:#1f497d"> </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Specifying shorter max validity periods for SHA-1 SSL certificates (1-year starting Jan 2015?)</span><u></u><u></u></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-</span><span style="font-size:7.0pt;color:#1f497d"> </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Setting end dates for the creation of any new Root and Subordinate CAs with SHA-1</span><u></u><u></u></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-</span><span style="font-size:7.0pt;color:#1f497d"> </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Defining clear messaging to the user community regarding SHA-1</span><u></u><u></u></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-</span><span style="font-size:7.0pt;color:#1f497d"> </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Setting target dates for the next set of changes for improved security/performance (RSA-4096/ECC/SHA-512/etc)</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’m against:</span><u></u><u></u></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-</span><span style="font-size:7.0pt;color:#1f497d"> </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Specifying an exact date at which no SHA-1 certificates can be issued globally</span><u></u><u></u></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-</span><span style="font-size:7.0pt;color:#1f497d"> </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Specifying the detailed legacy exceptions for using SHA-1 after the sunset date</span><u></u><u></u></p>
</div></blockquote><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">Here it starts again...this is exactly what I'm afraid of and thought we should avoid. I prefer an exact date binding for all, clear limits when and for how long. <u></u><u></u></p>
<div><p class="MsoNormal"><u></u> <u></u></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">A "Strong +1" to Eddy's remarks.<u></u><u></u></p></div><div><p class="MsoNormal">
<u></u> <u></u></p></div><div><p class="MsoNormal">I think if a CA is going to issue these 'legacy' certificates, it should be exactly the same process as handling other legacy practices - eg: 1024-bit roots.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">It gets treated as a BR violation, it's a qualified finding, and, most importantly for Root Store Operators/Browsers, precisely *because* it's a qualified finding, that practice gets disclosed to the Operators.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Chrome's plan continues to remain aggressive - disallowing certain algorithms/key sizes if their issuance date is after their sunset-grace period, outright rejecting them if their validity period exceeds the sunset-fail period, and eventually outright removing support entirely. As such, a CA that (continues) to issue such certs would not (ultimately) be causing outright risk to *current* versions of Chrome users.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">However, such a qualified finding *would* be a point of concern for overall trustworthiness, and *does* highlight that the CA is engaged in practices for specific customers that may be dangerous overall, and that's exactly the kind of thing a qualified finding can highlight. It's entirely possible (read: probable) that it would not be an immediate cause for removal, but would be something to work closely with the CA to ensure the BR violations cease on an appropriate timeline.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">This is the same way Operators are already handling legacy roots, and are already handling 1024-bit certs (eg: Symantec's BR-violating issuance of a <a href="http://pb.com" target="_blank">pb.com</a> cert - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=966350" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=966350</a> ), and is the way forward for these sorts of 'legacy' issues.<u></u><u></u></p>
</div></div></div></div></div></div></div></div></blockquote></div><br></div>