On Thu, 3 Mar 2016 08:25:52 -0800 Richard Barnes <[email protected]> wrote:
> Perhaps this is something we should clarify in the BRs or Mozilla > policy. While I'm glad an actual cert was not issued in this case, it > is important to maintain consistency between precertificates and > certificates, if only for the CT logs tell a consistent story. There's a more important reason, which is that if you can get a CA to sign a pre-cert using a weak hash algorithm, and that signature is conveniently published in a CT log, you can potentially exploit a collision to forge a valid, trusted certificate (the forgery need not contain the poison extension)[1]. Because of this, issuing a SHA-1 pre-cert is _just as bad_ as issuing a SHA-1 cert - there is no silver lining that the actual cert was not issued. It's also troubling that a CA may be allowed to continue issuing non-serverAuth certs with SHA-1 from an issuer that is also used for serverAuth certs. Again, a collision attack could be used to forge a trusted serverAuth cert. I urge that this hole be fixed in both Mozilla policy and the BRs, not just by clarifying the cert/pre-cert equivalence, but also by forbidding an issuer that is trusted for serverAuth from signing _anything_ with SHA-1. Regards, Andrew [1] Unless the precert was signed by a dedicated precert signing certificate, which was not the case here. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
