[cabfpub] SHA1 options for payment processors

[Peter Bowen]

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

There is no known SHA-1 collision attack yet, which means that keys that are logged today are probably still fine.

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.

Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160407/5b2afe2e/attachment-0003.html>