<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 12, 2014 at 4:36 PM, Eddy Nigg (StartCom Ltd.) <span dir="ltr"><<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
On 03/12/2014 02:51 PM, From Doug Beattie:
<div class=""><blockquote type="cite">
<div><br>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">So,
at this time, I’m in favor of:<u></u><u></u></span></p>
<p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Specifying
shorter max validity periods for SHA-1 SSL certificates
(1-year starting Jan 2015?)<u></u><u></u></span></p>
<p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Setting
end dates for the creation of any new Root and Subordinate
CAs with SHA-1<u></u><u></u></span></p>
<p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Defining
clear messaging to the user community regarding SHA-1<u></u><u></u></span></p>
<p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Setting
target dates for the next set of changes for improved
security/performance (RSA-4096/ECC/SHA-512/etc)<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)">I’m
against:<u></u><u></u></span></p>
<p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Specifying
an exact date at which no SHA-1 certificates can be issued
globally<u></u><u></u></span></p>
<p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Specifying
the detailed legacy exceptions for using SHA-1 after the
sunset date<u></u><u></u></span></p>
</div>
</blockquote>
<br></div>
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. <br><div class="">
<br></div></div></blockquote><div><br></div><div>A "Strong +1" to Eddy's remarks.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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">pb.com</a> cert - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=966350">https://bugzilla.mozilla.org/show_bug.cgi?id=966350</a> ), and is the way forward for these sorts of 'legacy' issues.</div>
</div></div></div>