<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 7, 2016, at 12:47 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 7, 2016 at 12:37 PM, Andrew Ayer <span dir="ltr" class=""><<a href="mailto:agwa@andrewayer.name" class="">agwa@andrewayer.name</a>></span> wrote:<br class=""><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 class=""><div class="gmail-h5">On Thu, 7 Apr 2016 11:36:31 -0700 Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:<br class="">> On Thu, Apr 7, 2016 at 11:34 AM, Peter Bowen <<a href="mailto:pzb@amzn.com" class="">pzb@amzn.com</a>> wrote:<br class="">><br class="">> > Doug,<br class="">> ><br class="">> > Would you be able to use the same subject public key and same<br class="">> > subject distinguished name as their previous certificate?<br class="">> ><br class="">> > Would you be able to use the same certificate profile as your<br class="">> > previously issued SHA-1 certificates?<br class="">> ><br class="">> > If both are true, then I think that the hash collision risk is<br class="">> > heavily mitigated.<br class="">> ><br class="">><br class="">> Agreed. Or, perhaps stated differently, if whatever changes is<br class="">> consistent for all such certificates (and, even more strongly,<br class="">> consistent with non-SHA1 certificates excluding the signature<br class="">> algorithm), the risk of a CA colluding seems mitigated.<br class=""><br class=""></div></div>How can the public be assured that the key being certified is really an<br class="">existing key? In this case, the existing certificates for<br class=""><a href="http://pos.azul.com.do/" rel="noreferrer" class="">pos.azul.com.do</a> and <a href="http://pos2.azul.com.do/" rel="noreferrer" class="">pos2.azul.com.do</a> were only logged to Certificate<br class="">Transparency logs today [1, 2]. As such, there is no good assurance<br class="">that these keys were generated before the January 1, 2016 sunset.<br class="">There's only the notBefore date signed by Symantec, which can't be<br class="">trusted under the threat model of a compromised or colluding CA.<br class=""><br class=""></blockquote><div class="">Andrew: I agree. There's no way for the public to independently verify such certificates under this model - it requires either trusting the CA (at their claim), the CA's auditor (who may or may not be examining such certificates), or a Certificate Transparency log. Only one of these has a verifiable means of determining non-collusion (a CT log can't backdate beyond lesser of the MMD or the last published STH without violating the CT Log's properties)</div></div></div></div>
</div></blockquote></div><br class=""><div class="">There is no known SHA-1 collision attack yet, which means that keys that are logged today are probably still fine.</div><div class=""><br class=""></div><div class="">I would posit that it might be acceptable to even allow a short window (say now until May 31, 2016) to log SHA-1 or SHA-2 certificates that will be eligible for “cloning” to SHA-1 certificates. However I would want to get an update from the team that published the free-start collision to see if they have made progress to a full collision before committing to that.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Peter</div></body></html>