On Wed, 17 Aug 2016 11:43:45 -0700 (PDT)
[email protected] wrote:
> On Wednesday, August 17, 2016 at 10:31:29 AM UTC-7, Andrew Ayer wrote:
> > The attacker has to be able to control (or predict) the prefix of
> > the data signed by the CA (which in the case of a TBSCertificate,
> > includes the serial number), as well as the prefix of the forged
> > certificate. However, they do not have to be the same, and their
> > similarity has no bearing whatsoever on the practicality of the
> > attack. In fact, the data signed by the CA need not even be a
> > TBSCertificate - if a CA signs an OCSP response with SHA-1, an
> > attacker could forge a certificate[1]. This is why action must be
> > taken at the level of the key doing the SHA-1 signing - that is,
> > the intermediate CA level.
> >
> > Regards,
> > Andrew
> >
> > [1]
> > https://www.mail-archive.com/[email protected]/msg02999.html
>
> Based on this statement I would assume we need to worry about root
> CAs issuing SHA-1 CRLs?
Fortunately not, as CRLs do not reflect attacker-controlled data. In
addition to having to control or predict the prefix of the signed data,
the attacker must be able to control the part of the signed data
following the prefix. With a TBSCertificate, that's accomplished
through the public key. With an OCSP response, that's accomplished
through either the nonce or the serial number, which are reflected from
the OCSP request (unless the request is pre-generated).
This page goes into greater detail (the picture in section 5.3 is
especially illustrative):
https://www.win.tue.nl/hashclash/rogue-ca/
Regards,
Andrew
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
