On Thursday, March 3, 2016 at 9:20:07 AM UTC-8, Andrew Ayer wrote: > 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.
A resounding +1 to this. This goes back to the core goal - if a certificate has id-kp-serverAuth / is in scope for the BRs, the only way to make a reasonable argument about the cryptographic operations is if _everything_ issued by that CA is seen in scope. This is not just a matter for SHA-1; consider an intermediate with id-kp-serverAuth and id-kp-emailProtection. If, in the issuance of S/MIME certificates, the CA leaves off the EKU from the leaf, and issues a commonName of "example.com", then that certificate - though intended for email - can now be used for TLS authentication. This is wholly independent of SHA-1 deprecation. For this reason, I'm a strong supporter in mandating that the scope of Mozilla's policies - and, more importantly, the expectation of BR compliance - extends to include _all_ certificates issued from an intermediates capable of causing TLS certificate issuance, even if those leaves are not intended for TLS. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
