> > 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.
We are actually taking steps to transition the issuance of client cert. to a new SubCA, which is separated from the SubCA issuing SSL cert. We are assuming that there is no need to separate into two roots, right? The new SubCA will be generated shortly and signed with SHA256 algorithm and its serial number contains at least 64 bits of entropy. > > 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" > If a whitelist would be considered, we're glad to provide information of currently valid SSL cert. There are currently around 135 valid SSL cert., which will continue to decrease month by month due to cert. expiry. > 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. I'd like to add that unlike SSL cert., we do not accept subscriber-supplied CSR for client cert. We take a central key generation approach for client cert. and then many manual steps to securely deliver client cert. to the subscriber. Therefore client cert. does not possibly contain attacker-controlled data. I'm not saying that it risk-free now, but such risk factor should be different from SSL cert. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
