On 12/07/2017 16:47, Ryan Sleevi wrote:
On Wed, Jul 12, 2017 at 10:19 AM, Hanno Böck via dev-security-policy <
[email protected]> 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.
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).
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.
Maybe it would be better stylistically to add this to one of the other
BR clauses.
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).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
