On Wednesday, August 17, 2016 at 2:53:38 AM UTC-7, [email protected] wrote: > Through our effort of sunsetting the "Hongkong Post e-Cert CA 1 - 10" for SSL > certificate, majority of SHA-1 SSL certificates will be expired by 31 Dec > 2016, remaining only a few SHA-1 SSL certificates that are valid beyond 1 Jan > 2017. And in our response to March 2016 CA Communication of Mozilla, we have > also committed to have those certificates revoked by 31 Dec 2016.
Unfortunately, I believe you've misunderstood the concern being raised here. "Hongkong Post e-Cert CA 1 - 10" is technically capable of issuing SSL certificates (that is, it's not constrained in any way to prevent it). We further know this precisely because it was, in the past, used to issue such certificates, and because in the present, it's still trusted for such certificates - because you have them expiring. However, because you've continued to issue new (non-SSL) SHA-1 certificates from this sub-CA, you create the risk that an attacker can exercise a SHA-1 collision on one type of a certificate (e.g. a client certificate) and transform it into another kind (such as an SSL intermediate CA). That's because regardless of what you signed with SHA-1 originally, an attacker can mutate it into any other type of cert. This is exactly the cause of the Flame MD5 Collision - a sub-CA only used to issue one type of certificate (Terminal Services certificates) wasn't appropriately restricted from other types (via the EKU on the intermediate), and an attacker was able to turn the Terminal Services certificate into a Code Signing certificate by using an MD5 collision. The further concern is because this CA isn't taking steps to prevent such attacks, such as by including sufficient entropy (20 bits under the previous SHOULD, 64 bits under the new MUST), which would make it much harder for an attacker to exploit this. So the question is now, since Hongkong Post / Certizen didn't properly protect this intermediate, what should Mozilla do, either for the intermediate or the root? For example, for the safety of its users, it could decide to distrust the "1 - 10" sub-CA. This wouldn't break any of your client cert use cases (or shouldn't), but would break all of those existing certificates. Mozilla could decide this was acceptable, or it could decide to whitelist those certificates as trusted. If the whitelist was too large to be included built-in, it might be hosted in some sharded, privacy-preserving way, much like Google SafeBrowsing does, or like CRLs in reverse. This is something the Chrome team is considering, for example, and depends on how many certificates issued by "1 - 10" Certainly, whatever the result, you should understand that by continuing the practices using "1 - 10", no matter what your intent is, you're actively putting people who trust your CA at risk, and that risk may be so great that people begin to distrust you. You should immediately take mitigations to prevent this - such as stopping the use of SHA-1 (ideally, immediately), or revoking that "1 - 10" sub-CA and reissuing your certificates, in a SHA-256 way, to consumers who might be affected by that. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
