I'm not generating a lot of keys… 😉 The last time I used openssl to generate a keypair it took a few seconds. But of course, you're right, it scales as it's done on the subscriber side.
-Roman From: Mike Shaver <[email protected]> Sent: Freitag, 1. November 2024 13:39 To: Roman Fischer <[email protected]> Cc: [email protected] Subject: Re: Assuming keyCompromise for unspecified-reason revocations Key generation is done by the subscriber, generally, which means it seems like it would scale pretty well given that it happens at the rate of certificate replacement. Even at an imagined 3-day validity window, that’s a pretty small amount of cryptography to amortize. My phone could have done it while I typed the last sentence without me noticing, I think. That said, you probably generate more keys than I do: what does it cost to generate your preferred (classical, not PQ let’s say) key pair for a modern certificate on your choice of modern data centre CPU? The perfect doesn’t need to be the enemy of the good here; we can start by just having CAs track one they’ve seen before. If subscribers think it’s easier to change CAs than to generate another key, then we’re in a pretty good place as an ecosystem I think! Mike On Fri, Nov 1, 2024 at 8:28 AM Roman Fischer <[email protected]<mailto:[email protected]>> wrote: Key-generation isn't that cheap and the larger the keys get, the more expensive it gets. Also, the CA's would probably need to feed and query one central database of "used" keys to prevent the re-use. -Roman From: Mike Shaver <[email protected]<mailto:[email protected]>> Sent: Freitag, 1. November 2024 13:16 To: Roman Fischer <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: Assuming keyCompromise for unspecified-reason revocations I guess I’m curious about the opposite question: why is it important that a key be permitted to be reused ever? I understand that there are some operational shortcuts that can be taken to avoid deploying a new key along with a new certificate, but I’m not sure if there are other reasons to not just require a new private key for every certificate. They are cheap to generate! I feel a nagging at the back of my brain as I ask this question, so I anticipate that someone will provide a tremendously obvious answer. Mike On Fri, Nov 1, 2024 at 6:00 AM Roman Fischer <[email protected]<mailto:[email protected]>> wrote: Dear Jamie, I don't see what's the final goal here. Is it to prohibit anybody from re-using any key that was ever involved in a certificate that was revoked (any reason could be "false" or "mistaken")? Or also keys of certificates that expired (not everybody who has a key compromise reports it or revokes the certificate, they might just create a new key and let the cert expire)? Kind regards Roman From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Jaime Hablutzel Sent: Freitag, 1. November 2024 05:23 To: [email protected]<mailto:[email protected]> Cc: Aaron Gable <[email protected]<mailto:[email protected]>> Subject: Re: Assuming keyCompromise for unspecified-reason revocations 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]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[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<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/00f38a3e-f2b7-4000-bb3a-ac8d756c95cfn%40mozilla.org?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "[email protected]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB01706BA4FE843FF7A2E982D3FA562%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB01706BA4FE843FF7A2E982D3FA562%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "[email protected]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB0170549AE9570AF075D265A0FA562%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB0170549AE9570AF075D265A0FA562%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>. -- 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/ZR0P278MB0170862C92669CC39F95C35DFA562%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.
