On Fri, Jul 14, 2017 at 1:29 AM, Jakob Bohm via dev-security-policy < [email protected]> wrote: > > But that doesn't clearly include keys that are weak for other reasons, > such as a 512 bit RSA key with an exponent of 4 (as an extreme example). >
Yes. Because that's clearly not necessary - because it's already covered by 4.9.1.1 #3 and 6.1.5/6.1.6. So I don't think this serves as a valid criticism to the proposed update. > Maybe it would be better stylistically to add this to one of the other > BR clauses. > Considering that the goal is to make it clearer, I'm not sure this suggestion furthers that goal. > Anyway, I think this is covered by BR 4.9.1.1 #3, although it might not > be obvious to the CA that they should have set up checks for this, since > most key compromise reports come from the subscriber, who would be a lot > less likely to make this mistake after revoking the key themselves, > except when the revocation was mistaken (this happens, and in that case, > reusing the key is not a big problem). > I'm afraid you may have misunderstood the point. Certainly, 4.9.1.1 #3 covers revocation. However, my suggestion was about preventing issuance, which is why I was talking about 6.1.1.3. That is, unquestionably, if a CA revokes a certificate for key compromise, then issues a new one for that same key, they're obligated under 4.9.1.1 #3 to revoke within 24 hours. My point was responding to Hanno's suggestion of preventing them from issuing the second certificate at all. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
