On Wed, Jul 12, 2017 at 10:19 AM, Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > * Comodo re-issued certs with the same key. I wonder if there should be > a rule that once a key compromise event is known to the CA it must > make sure this key is blacklisted. (Or maybe one of the existing > rules already apply, I don't know.) >
BRs 1.4.5 6.1.1.3 only requires the CA to reject a certificate if it doesn't mean 6.1.5/6.1.6 or is known weak private key. While the example is given (e.g. Debian weak keys), one could argue that 'weak' includes 'disclosed'. Of course, given that the specific term "Key Compromise" is also provided in the BRs, that seems a stretch. One could also argue 6.1.2 is applicable - that is, revocation was immediately obligated because of the awareness - but that also seems tortured. Probably the easiest thing to do is update the BRs in 6.1.1.3 to replace "known weak private key" to just say "If the private key is suspected or known to have suffered Key Compromise" - which includes known weak private keys, as well as the broader sense. One challenge to consider is how this is quantified. Obviously, if you reported to Comodo the issue with the key, and then they issued another certificate with that key, arguably that's something Comodo should have caught. However, if you reported the compromise to, say, ACME CA, and then Comodo issued an equivalent cert, that's questionable. I'm loathe to make CAs rely on eachothers' keyCompromise revocation reasons, simply because we have no normative guidance in the BRs (yet) that require CAs be honest or competent with their revocation reasons (... yet). Further, we explicitly don't want to have a registry (of compromised keys, untrustworthy orgs, etc), for various non-technical reasons. I'm curious if you have thoughts there - particularly, how you reported the private key was compromised (did you provide evidence - for example, a signed message, or simply a link to "Here's the URL, go see for yourself"?) - and how you see it working cross-CA boundaries. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
