Question re: Change in Revocations Methods

No, it is not. Consider the following situation:

  1. A large entity (call them Foo Co.) owns hundreds of domains, requests separate certificates for all of them, but uses the same keypair for all of those certificates.
  2. That entity sells one of its domain names to someone else (call them Bar Inc.).
  3. Bar Inc. gets a certificate for its own domain name. It has now demonstrated control over that domain name.
  4. Bar Inc. decides to revoke Foo Co's old certificate for that name. They can do this because they've demonstrated control over that name.
  5. Buuuut... Bar Inc. decides to put the revocation reason as "keyCompromise". What happens now?

The options are:
a) the CA trusts that the revocation reason is correct, revokes the requested cert, and revokes every other cert issued to Foo Co. with that same key; or
b) the CA does process the revocation, but doesn't also revoke all the other certs, thus being in violation of the Baseline Requirements; or
c) the CA refuses the revocation request, because key compromise has not been demonstrated.

The first two options clearly are not viable. The first one allows anyone who buys a domain from Foo Co to then cause every cert issued to Foo Co. to be revoked, even though they've demonstrated no control over those certs or their keys. The second one is a violation of the BRs. The only viable option is (c), which is what this post is about.


Unless I'm a corrupt politician who wants to shut down your server without actually having any proof that the key has been compromised. Think like a villain here, my friend. :smiling_imp:


@aarongable Thanks, that makes sense. I did not fetch this from the bug report I'm afraid, but I understand the reasoning behind it now.


So, you're starting to almost convince me that using only control-over-domain-names for keyCompromise revocation shouldn't be allowed (maybe, though in your example Foo Co. should have revoked their own certificate before transferring to Bar Inc. anyway per section 3.2 of the subscriber agreement, though I don't know if that means it couldn't later be additionally-revoked for keyCompromise). I still don't see why the account key originally used to issue the certificate can't then be used to revoke that cert for keyCompromise. Isn't the owner of the account key definitely the entity that can confirm that a certificate private key was stolen?

That is, in a setup where there's a centralized system for getting certificates (which I think is described as "edge case" above, though I wouldn't have thought it was that weird for larger integrators) that then pushes the certificates out to servers, if one server is hacked/stolen/wiped in such a way that the owner thinks the cert private key is compromised but no longer has access to it, I would have expected that that would be enough to convince the CA that the key was compromised. But it sounds like such a system needs to now ensure that all certificate private keys are backed up in order to ensure they could be later revoked, rather than just needing to back up the account key.


Really, the more I think about it, in that scenario it's really entirely on Foo Co. to have revoked their certificate (or maybe we need to establish some new way of disclaiming the domain names in ACME if needed) before selling the domain to Bar Inc. As was discussed in another thread here recently, if someone loses access to the certificate private key entirely (like it physically gets stolen, or the attacker wipes it after copying the key and other data from it), up until this change the standard approach to recover would be to just create a new ACME account, authorize the names, and use that to claim the old key was compromised. If one can't do that now, then I think you're going to end up with people either just not letting you know keys are compromised since they can no longer "prove" it with the certificate key, or they'd need to keep more certificate key backups (making the risk of a cert key compromise more likely).

Should this change really have happened back in July when CPS 4.0 updated section 4.9.12 to say only the private key of the cert could be used to demonstrate key compromise? At the very least, there probably should have been an API Announcement post at that time with an overview of the CPS changes. Somehow I'd missed that section when I was trying to understand what was happening, but now it looks like it was at least kind of documented since then, at least for people meticulous about looking at updated policy documents.


I feel that there's a certain irony here in that the application of the current proof of key compromise in the virtual world would be a catch-22 in the physical world.

Victim: :pensive: I've lost my key and need a rekey.

Locksmith: Prove it.

Victim: :worried: How?

Locksmith: Produce the key and demonstrate its validity.

Victim: :angry: If I had my key, I wouldn't need you.

Locksmith: Sorry, those are the rules.

There's a difference between losing control of a copy of a key and losing control of the copy of a key. Frequently with certificate keys there is but one copy. If it is compromised and access to it is lost, we have a catch-22.

I really am Bob Smith.

No you're not. See. I've got his driver's license right here.


Yeah, in many ways cryptography keys are more analogous to the usage of the word "key" in the phrase "answer key" than in the phrase "lock and key". But in either case, you don't want to lose your only copy. :slight_smile:


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 with a CSR for that key with CN=This key is compromised or some other standard form like the 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 :roll_eyes:

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.

there was old thread on mozilla sec forum about someone got certificate for random domain with LE X3's public key from digicert.


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.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.