Hi Aaron. Thanks for replying. On Tuesday, October 29, 2024 at 8:03:59 PM UTC-5 Aaron Gable wrote:
On a recent bugzilla ticket <https://bugzilla.mozilla.org/show_bug.cgi?id=1927532#c1>, a commenter (BCC'd) asks: > Isn't there a chance that some subscribers are omitting the revocation reason even for key compromise revocations? > ... > Isn't it better to err on the side of caution for this type of issues and additionally prevent the reuse of keys whose certificate has been revoked with reason “unspecified” considering that some of them might be compromised? I'd like to take a moment to reply because I believe this discussion is interesting, but I'm doing so here because I believe it is off-topic for that incident ticket. The issue contained in that preliminary report has to do with handling of revocation requests that specified the keyCompromise reason, not handling of revocation requests that did not specify a reason. Jaime, I think it would be a bad idea to assume that all certificates revoked with reason "unspecified" have actually had their keys compromised. I have four arguments: First, I see no argument that it is *more* likely that any given unspecified revocation actually be a keyCompromise than that it actually be a cessationOfOperation or some other reason. In fact, I think it is quite likely that the vast majority of unspecified revocations most closely match the superseded revocation reason: this would be the case any time a Subscriber automatically revokes their old certificate after renewing or replacing it. I can see an obvious counter-argument here: sure, maybe they're almost all actually "superseded", but we should assume the worst, just in case! But that gets right at my second reason this would be a bad idea: the root programs use revocation reasons to inform their own trust behavior. For example, it is my understanding that the CRLite updates its list of keyCompromise-revoked certs (and pushes the resulting bloom filters to Firefox installs) much more frequently than for other revocation reasons. This compromise ensures that keyCompromise revocations are handled as quickly as possible, while saving bandwidth by not updating the whole list every time. Which brings me to my third reason: treating all unspecified revocations as keyCompromises would increase the number of compromised keys by several orders of magnitude. The minutes of the latest CA/Browser Forum Face-to-Face include a presentation from Ben Wilson at Mozilla <https://github.com/cabforum/cabforum.org/blob/5a4119c89a106262254a4e6fe7f29b157bc37f2f/content/posts/2024/2024-10-f2f63-seattle/forum/5-October-2024-Mozilla-News.pdf> which shows that, globally, keyCompromise revocations comprise about 0.2% of revocations while unspecified comprises about 21%. The 0.2% reported in the F2F is for revocations where an explicit `keyCompromise` reason code was used. For sure that number is higher for revocations using the `unspecified` reason code where the intention was to revoke because of a key compromise, but how much I can't tell. Now, in case of vulnerabilities like Heartbleed, surely a lot more `unspecified` revocations would actually be because of key compromise. Increasing the number of keyCompromise revocations by 100x would not only drastically increase the bandwidth usage of systems like CRLite, but it would drastically increase the storage costs of CAs. A compromised key is compromised *forever*, and therefore must be retained forever. A technique like the one used by CRLite (i.e. Bloom filters) possibly could help on reducing these storage costs. Additionally, another option to consider might be the proposed called Private Key Compromise Transparency / PKCT (https://mailarchive.ietf.org/arch/msg/trans/tB8YhAapz_6RN9MJVMKlRCR9HK0/). And so finally, the strongest reason of all: per the Baseline Requirements, if a CA treats a key as compromised, then they are required to revoke all other certificates which share that key within 24 hours. One option here would be not to directly assume `unspecified`s as `keyCompromise`s, but still require CAs to prevent reuse of these keys, as some of them will be effectively compromised! Therefore a CA has a prerogative to treat a key as compromised *only *when that compromise has been demonstrated (e.g. by seeing the private key themselves, receiving an ACME revocation request signed by that key, or receiving a CSR with a "this key is compromised" subject signed by that key). Otherwise they open themselves up to denial-of-service attacks: a malicious actor could identify a victim site, apply for a certificate containing the same public key, revoke that certificate with reason unspecified, and let the CA do the rest of the work to treat that as a keyCompromise and revoke the target site's cert as well. Why the TLS BRs don't require certificate requests to include all the requested domains signed by the private key (e.g. with a CSR)? This is required by ACME already. If that is a requirement, an attacker could not successfully request a certificate using only a victim's public key or even a genuine CSR, as he could not complete DCV to get a certificate to revoke later. Doesn't it eliminate the potential DoS mentioned before? So while I think this is an interesting line of thinking, treating unspecified revocation requests as keyCompromise revocations and blocking those keys would be very bad for browsers, CAs, and the WebPKI as a whole. Aaron -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/00f38a3e-f2b7-4000-bb3a-ac8d756c95cfn%40mozilla.org.
