On 03/03/16 19:48, Ryan Sleevi wrote: > 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.
And I'd guess that (based on lack of EKU and existence of rfc822Name SAN) this SHA-1 certificate is an example of precisely that problem: https://crt.sh/?id=15019496 (used in the wild for a TLS server as of this writing: https://censys.io/ipv4/194.145.239.217) > > 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
