Because that's an assertion of key compromise, not a demonstration of key compromise. That's all.
Unfortunately it doesn't matter if any of the actors in this hypothetical should have behaved differently. The CA has to handle the situation gracefully anyway.
Again, "demonstration of key compromise" and "request for revocation" are not the same thing. That change was made to the CPS to ensure that security researchers who find compromised keys in the wild to use our API to report them, rather than emailing large dumps that have to be processed manually. The bug that we were willing to revoke with reason "keyCompromise" without having seen a demonstration of that key compromise is separate from requiring that key compromise demonstrations come in a specific format. And of course there was no API Announcement when we fixed this bug, due to the embargo.
Wait a minute. You mean that if I were to have my cert key compromised, and I emailed cert-prob-reports@letsencrypt.org with a CSR for that key with CN=This key is compromised or some other standard form like the pwnedkeys.com JWS format, that Let's Encrypt wouldn't be obligated to revoke it due to section 4.9.12 of the CPS saying that key compromise must be demonstrated by the ACME protocol? I certainly understand Let's Encrypt preferring usage of the automated endpoint, but I was under the impression that any report of key compromise sent for the humans to handle would also need to be handled just as well, even if it were a large number of requests. Or is this more of the difference between "demonstration of key compromise" and "request for revocation" that I'm clearly not fully wrapping my head around?
Thanks for answering, I had thought that I'd understood how this all works but this whole change has my head spinning. It's not just about what theory and specs say, but also about making sure I (and others) understand how am I supposed to set up and secure my systems to prepare for how to handle a key compromise situation. The Integration Guide should probably include some more information about the pros and cons of reusing keys across certificates, and about tracking certificate keys now that not all requests can be done with just the account key alone.
This is essentially correct. By the Mozilla Root Program Requirements, "Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods that parties may use to demonstrate private key compromise." Our CPS does not obligate us to accept a key compromise report consisting of a CSR signed by the supposedly-compromised private key emailed to cert-prob-reports@.
We of course may revoke the cert anyway. Our Subscriber Agreement states that "ISRG will determine, in its sole discretion, whether to revoke Your Certificate." And if you email the private key to us directly, then of course we would be obligated to revoke, as having the key in our possession is incontrovertible demonstration of key compromise. But again: please do not do these things. Use the ACME API to revoke certs, both for key compromise and otherwise, because we currently have active certs for approximately 200 million private keys and email and manual revocation do not scale.
Thanks again for the answer. I do understand that in practice if it were like just me with a couple certs emailing with reasonable evidence of compromise you'd probably take pity on me and revoke anyway, even if with a security researcher trying to send you thousands you'd just point them to the ACME API, but it's interesting and surprising to me that you wouldn't be under any obligation to do so without having the key itself in hand.
But that whole "demonstration of key compromise" is based entirely on an assumption anyway, as you've said earlier, soooooooo
All this stuff, also at the root programs, is a complete minefield of assumptions and generics.
If you just think of it logically, removing "proof of hostname ownership" as a method of revoking a cert makes sense. Removing the method of revoking using an account key doesn't. Root programs may imply otherwise, but it's also possible root programs don't entirely hold the whole truth and nothing but the truth..
Reading between the lines of what @aarongable has written, it seems pretty clear that LetsEncrypt is trying to find a delicate balance between doing what is required by the Root Program, providing the security and ease-of-use required by Subscribers, and protecting their global infrastructure against very common mistakes and anti-patterns.
Would it be easier for a compromised subscribe if only an Account Key were necessary via the API to mark something as compromised? Absolutely! Unfortunately, the production environment has shown that mechanism to be wildly susceptible to misuse and abuse by most client developers (myself included!) So .00001% of subscribers in an edge case may have to manually work through some steps, while 99.999999% of subscribers and all their users will have a more stable platform to rely upon.
Yeah, I certainly recognize that the good people at Let's Encrypt understand the complexities of the CAB/Root requirements, the WebPKI in general, and their own platform specifically all much better than I do. I just would have naively thought the prior behavior was everything behaving as expected and documented, even in the revoking-for-keyCompromise-by-only-proving-domain-ownership cases (like, we recommended it as the best way to do things here just a couple weeks ago), so the fact that the behavior was actually considered a bug (and not just any bug, one that needed to be embargoed for 8 weeks for other platforms to be able to "patch") has really just thrown me for a loop.
If this new way really is The Right Way to do things, though, then I think the next step is really getting a lot more details and recommendations into the documentation, especially in the Integration Guide and ACME Implementation Details, as well as making sure ACME clients update their behavior. Like, the revoking documentation says that Certbot will use the account key by default, which I'm guessing means that if you add --reason keyCompromise it just won't work unless you also add the --key-path parameter? I would guess that it should be smarter about picking which key to sign the request with based on the revocation reason now.
I guess the other main thing I'm trying to say is that if revoking for key compromise becomes harder, then people may be more likely to just not report it at all instead, or revoke it for some other reason leading to it not ending up on the blocked-key-list even when it should, so it's in everyone's best interest to ensure that key compromise revocation is easy enough to be able to actually happen when it's needed.
I see this as a bit if a zugzwang trust situation.
Either trust that the reported key has been compromised when "wolf" is cried if acceptable "proof" has been provided (where possession of a key isn't really logical proof of key-compromise so much as proof of an identity of vested interest) or ignore the cry and allow the compromise to unfold.
Obviously the latter defeats the purpose and is unacceptable. The former unfortunately places the burden of the cry on the CA and the WebPKI in general rather than on the (real or fake) victim.
It's like multitudes of tenants losing their keys and the landlord footing the bill for them all and mitigating by placing bureaucracy in place that makes everyone's lives more difficult.
this feels like it was possible to get a certificate of public key without actually having to show proof of they have private key for it. this by itself isn't againest rule, but boulders csr.go do check csr's self sign so it's unlikely this to be reason.
or some shared hosting soultuion like #33 give csr for any domain with it's public key when client ask for custom certificate, as they don't think csr itself as private infomation.
Eh, I see this more as a creative use of the consortium rules to operate in the manner which is best positioned to provide their service (i) automated, and (ii) on a global scale. As one of their employees mentioned above, a manual option exists to handle edge cases, and we know they would try to do the right thing for each Subscriber - but they can't guarantee that.
If they were to guarantee something, or state a position on this policy otherwise, the would be bound by consortium rules to operate in a certain prescribed manner - a manner which drastically complicates and potentially jeopardizes their operations (for many reasons all discussed above).
Their position on this matter may not be the easiest for consumers, but is 100% in compliance with consortium rules - which they must adhere to.
I wasn't referring to the manual aspect particularly though. I was referring to revocation from key-compromise reports in general. Other than to be annoying and waste resources, there's really not much motivation for intentional submission of false reports of key-compromise by bad actors (for keys they actually possess). On the other hand, I do believe there is great misconception (or maybe call it laziness of understanding) out there about what comprises a key-compromise, which results in unintentional submission of false reports of key-compromise by misinformed actors. Hence why I created and frequently reference this:
The current "burden of proof" does not prevent submission of false reports from either of those two classes of keyholder, but it does prevent submission of true reports from likely the most vulnerable class of keyholder (those who have lost possession of their keys). It's a tradeoff that halts the other class of keyholder (or should I say non-keyholder) who intentionally submits false reports of key-compromise (for keys they don't actually possess).
... was designed to prevent the repeat of specific Denial of Service attack vector, which recently occurred.
In the event of a Key Compromise, there are numerous ways to immediately mitigate the situation, including at least:
Revoke the Certificate with the issuing ACME Account Key, citing any other reason
Revoke the Certificate with a new ACME Account Key, after proving control of the domain, citing any other reason
The new rules only mean the Private Key MUST be submitted to trigger:
the NECESSARY revocation of all Certificates sharing that Private Key (based on CA/B rules)
registry of the Private Key onto the blocklist
inclusion of the revocation in KeyCompromised metrics
The Subscriber can still revoke the Certificate, they simply can't cite the reason as "KeyCompromised" without proof of the key, nor can they enjoy the streamlined benefits afforded by that reason. This tradeoff is negligible when compared to the security offered by addressing the previous vulnerability.
