[cabfpub] SHA1 options for payment processors

Ryan Sleevi sleevi at google.com
Thu Apr 7 12:47:52 MST 2016


On Thu, Apr 7, 2016 at 12:37 PM, Andrew Ayer <agwa at andrewayer.name> wrote:

> [Ryan, please forward this to the CABFPub list. Thanks!]
>
> On Thu, 7 Apr 2016 11:36:31 -0700
> Ryan Sleevi <sleevi at google.com> wrote:
>
> > On Thu, Apr 7, 2016 at 11:34 AM, Peter Bowen <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.
>
> Ryan and Peter,
>
> 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 and 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.
>
> Regards,
> Andrew
>
> [1] https://crt.sh/?id=16309943
> [2] https://crt.sh/?id=16309893
>

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160407/9cbc7924/attachment.html 


More information about the Public mailing list