<div dir="ltr"><div class="gmail_extra"><br class="gmail-Apple-interchange-newline"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 12:37 PM, Andrew Ayer <span dir="ltr"><<a href="mailto:agwa@andrewayer.name">agwa@andrewayer.name</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">[Ryan, please forward this to the CABFPub list. Thanks!]<br><div><div class="gmail-h5"><br>On Thu, 7 Apr 2016 11:36:31 -0700<br>Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:<br><br>> On Thu, Apr 7, 2016 at 11:34 AM, Peter Bowen <<a href="mailto:pzb@amzn.com">pzb@amzn.com</a>> wrote:<br>><br>> > Doug,<br>> ><br>> > Would you be able to use the same subject public key and same<br>> > subject distinguished name as their previous certificate?<br>> ><br>> > Would you be able to use the same certificate profile as your<br>> > previously issued SHA-1 certificates?<br>> ><br>> > If both are true, then I think that the hash collision risk is<br>> > heavily mitigated.<br>> ><br>><br>> Agreed. Or, perhaps stated differently, if whatever changes is<br>> consistent for all such certificates (and, even more strongly,<br>> consistent with non-SHA1 certificates excluding the signature<br>> algorithm), the risk of a CA colluding seems mitigated.<br><br></div></div>Ryan and Peter,<br><br>How can the public be assured that the key being certified is really an<br>existing key?  In this case, the existing certificates for<br><a href="http://pos.azul.com.do/" rel="noreferrer">pos.azul.com.do</a> and <a href="http://pos2.azul.com.do/" rel="noreferrer">pos2.azul.com.do</a> were only logged to Certificate<br>Transparency logs today [1, 2].  As such, there is no good assurance<br>that these keys were generated before the January 1, 2016 sunset.<br>There's only the notBefore date signed by Symantec, which can't be<br>trusted under the threat model of a compromised or colluding CA.<br><br>Regards,<br>Andrew<br><br>[1] <a href="https://crt.sh/?id=16309943" rel="noreferrer">https://crt.sh/?id=16309943</a><br>[2] <a href="https://crt.sh/?id=16309893" rel="noreferrer">https://crt.sh/?id=16309893</a><br></blockquote><div><br></div><div>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>