# Question re: Change in Revocations Methods **URL:** \ **Category:** Issuance Policy\ **Created:** [December 13, 2021, 11:38pm UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634 "2021-12-13T23:38:10Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![jillian](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jillian/32/11635_2.png) [@jillian](https://community.letsencrypt.org/u/jillian)\ **Post date:** [December 13, 2021, 11:38pm UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/1 "2021-12-13T23:38:10Z")
Discussion thread for [Change in Revocation Methods Due to a (now patched) ACME bug](https://community.letsencrypt.org/t/change-in-revocation-methods-due-to-a-now-patched-acme-bug/167633/2) ---
**Author:** ![jillian](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jillian/32/11635_2.png) [@jillian](https://community.letsencrypt.org/u/jillian)\ **Post date:** [December 13, 2021, 11:39pm UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/2 "2021-12-13T23:39:08Z")
---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [December 13, 2021, 11:50pm UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/3 "2021-12-13T23:50:17Z")
I feel like the following logical proposition implies that only the keyCompromise reason should be used any time one is revoking using the certificate private key, which seems inverted and/or overly limiting. > [@Change in Revocation Methods Due to a (now patched) ACME bug](https://community.letsencrypt.org/t/change-in-revocation-methods-due-to-a-now-patched-acme-bug/167633/1): > > only requests the “keyCompromise” revocation reason when revoking using the certificate private key. That seems to imply: If/when revoking using the certificate private key, only request the "keyCompromise" revocation reason. While I first admit that revocation reasons are not my strong suit in ACME, are there other reasons for requesting revocation using the certificate private key, such as decommissioning? Should the quoted block be worded: > only requests revocation using the certificate private key (or ACME account key) when the “keyCompromise” revocation reason is used. That seems to imply: If/when the "keyCompromise" revocation reason is used, only revoke using the certificate private key (or the ACME account key). ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [December 13, 2021, 11:50pm UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/4 "2021-12-13T23:50:54Z")
🎉 Woo hoo! I never liked this implementation detail, and felt it was a potential issue but never had time to explore further. I'm glad to see it removed! ---
**Author:** ![aarongable](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/aarongable/32/42043_2.png) [@aarongable](https://community.letsencrypt.org/u/aarongable)\ **Post date:** [December 13, 2021, 11:54pm UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/5 "2021-12-13T23:54:14Z")
A client can sign the revocation request using the certificate private key, but request a reason code other than "keyCompromise" -- doing so is normal behavior when the key has not been compromised but the original subscriber and key-holder is requesting revocation for some other reason. ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [December 13, 2021, 11:56pm UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/6 "2021-12-13T23:56:40Z")
Check my implication statements if you would, @aarongable. Maybe I missed something. Your response seems to indicate my concerns about what I quoted from @jillian. ---
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [December 14, 2021, 12:08am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/7 "2021-12-14T00:08:25Z")
The potentially supported reason codes are defined in [RFC5280 Section 5.3.1](https://datatracker.ietf.org/doc/html/rfc5280#section-5.3.1). Though I don't believe Boulder or any ACME CA currently accepts all of these. ```nohighlight CRLReason ::= ENUMERATED { unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), -- value 7 is not used removeFromCRL (8), privilegeWithdrawn (9), aACompromise (10) } ``` > [@griffin](#): > > That seems to imply: > > If/when revoking using the certificate private key, only request the "keyCompromise" revocation reason. Regardless of whether you _should_ be revoking in the first place due to something other than a compromise, there seem to be a few legit non-compromised reasons you could use. Superseded or CessationOfOperation are probably the ones that make the most sense to a casual user. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [December 14, 2021, 12:08am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/8 "2021-12-14T00:08:58Z")
I concur with @griffin here. The explanation as stated by Aaron is the opposite as explained by Jillian? The code supports the "if key compromise is the reason, then only private key revocation is possible" narrative, while Jillian states the opposite: "if the private is used for revocation, only key compromise as reason is allowed".. The former is of course logic, the latter isn't to me? ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [December 14, 2021, 12:09am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/9 "2021-12-14T00:09:59Z")
@Osiris I also think the ACME account key could be used when key compromise occurs. See my amended post. Does the expanded logic sound right to you? Just checking my brain here. ---
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [December 14, 2021, 12:14am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/10 "2021-12-14T00:14:29Z")
> [@griffin](#): > > I also think the ACME account key could be used when key compromise occurs. No, that was the bug, right? Post-bugfix, you're now only allowed to use KeyCompromise as the reason when you actually sign the revocation request with the (compromised) private key. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [December 14, 2021, 12:14am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/11 "2021-12-14T00:14:33Z")
I'm not sure if this whole bug is a bug to begin with. If someone revokes a certificate with key compromise as reason, I would not dare to even care _how_ it got revoked. What if the server was hacked and the key was no longer in possesion of the rightful owner of the cert? Then there would be no way to revoke it... I'm genuinly questioning this decision of Let's Encrypt, although I haven't read the Mozilla bugreport yet. ---
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [December 14, 2021, 12:16am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/12 "2021-12-14T00:16:19Z")
> [@Osiris](#): > > What if the server was hacked and the key was no longer in possesion of the rightful owner of the cert? Then there would be no way to revoke it... You can still revoke it, just not using the KeyCompromise reason which triggers the auto-revocation of the rest of the certs using it as well. If all of your servers with certs using that key are hacked or destroyed, then you need to re-prove control over the domains and revoke each individually (or use the account key). ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [December 14, 2021, 12:16am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/13 "2021-12-14T00:16:29Z")
? Why couldn't I use the ACME account key to revoke a compromised certificate? I thought the bug was allowing the use of proof of control of all SANs for revocation. Admittedly, this wording in [Change in Revocation Methods Due to a (now patched) ACME bug](https://community.letsencrypt.org/t/change-in-revocation-methods-due-to-a-now-patched-acme-bug/167633) supports the confusion: > [@Change in Revocation Methods Due to a (now patched) ACME bug](https://community.letsencrypt.org/t/change-in-revocation-methods-due-to-a-now-patched-acme-bug/167633/1): > > The fix was to ensure that the certificates can only be revoked with reason “keyCompromise” when the revoker has demonstrated control over the certificate’s private key directly. That statement makes no mention of the ACME account key at all. I think it should. > [@Osiris](#): > > What if the server was hacked and the key was no longer in possesion of the rightful owner of the cert? Then there would be no way to revoke it... Exactly my concern. Of course, the ACME account key sitting on that server is likely compromised right along with the certificate private key. 😔 ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [December 14, 2021, 12:25am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/14 "2021-12-14T00:25:15Z")
I'm just going to explain the situation, as I see it, like a fifth grader: The ACME Specification dictates that any certificate revocation marked with "KeyCompromise" _requires_ the CA to revoke all other certificates that share the same Private Key. It's a chain reaction. This means that when revoking a certificate for Domain A, if one marks it compromised, all other certificates that share the key must be revoked by the CA. Because this will have an effect on other certificates, the fix to Boulder/Pebble requires proof of controlling the private key when asserting that key is compromised. One can still revoke the certificate for other reasons, as @rmbolger noted, which do not start the chain reaction of revocation. > [@griffin](#): > > I also think the ACME account key could be used when key compromise occurs. IMHO, the issuing ACME Account Key _should_ be enough to trigger the chain reaction. I can think of one edge case where someone might have the issuing account key, but no longer have access to private key. This is a bit of an edge case though, and there are likely far fewer users who would benefit from supporting it, than the number of users who benefit from getting the current fix out. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [December 14, 2021, 12:26am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/15 "2021-12-14T00:26:43Z")
> [@rmbolger](#): > > You can still revoke it, just not using the KeyCompromise reason which triggers the auto-revocation of the rest of the certs using it as well. > > If all of your servers with certs using that key are hacked or destroyed, then you need to re-prove control over the domains and revoke each individually (or use the account key) And thus the whole reason of revoking with reason key compromise is nullified by that.. If I had thousands of certs using the same private key (as in the bugreport) and I was only able to revoke individually... Yeah, right.. Also, even after reading the bugreport, the whole necessity or legitimacy of this "bug" is not clear to me at all. The only bug I'm seeing here, someone revoked a cert with the incorrect reason which had tremendous consequences.. Human error. Not a bug in the way certs could be revoked. ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [December 14, 2021, 12:27am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/16 "2021-12-14T00:27:08Z")
I can see an edge case as you've mentioned, @jvanasco, with centralized issuance. 👁 ---
**Author:** ![rmbolger](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rmbolger/32/27474_2.png) [@rmbolger](https://community.letsencrypt.org/u/rmbolger)\ **Post date:** [December 14, 2021, 12:27am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/17 "2021-12-14T00:27:22Z")
> [@jvanasco](#): > > This means that when revoking a certificate for Domain A, if one marks it compromised, all other certificates that share the key must be revoked by the CA. And I would hope that people using the same private key for multiple different certs is exceedingly rare. But maybe there are weird edge cases I'm not considering. ---
**Author:** ![aarongable](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/aarongable/32/42043_2.png) [@aarongable](https://community.letsencrypt.org/u/aarongable)\ **Post date:** [December 14, 2021, 12:29am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/18 "2021-12-14T00:29:04Z")
Ah, I understand the confusion. We're using different readings of the word "only". The main paragraph is the one you should pay the most attention to, and use as context to inform your reading of the rest of the statement: > The fix was to ensure that certificates can only be revoked with reason “keyCompromise” when the revoker has demonstrated control over the certificate’s private key directly. The statement causing confusion is > If you maintain an ACME client, please ensure that your client... only requests the “keyCompromise” revocation reason when revoking using the certificate private key. Your reading is "when revoking using the certificate private key, only request the keyCompromise reason code". The intended reading is "only request the keyCompromise reason code if/when you are revoking using the certificate private key -- if you are revoking via some other method, don't request the keyCompromise reason code, because it won't work". ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [December 14, 2021, 12:29am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/19 "2021-12-14T00:29:48Z")
We like to think of certs and keys as one-to-one, but there's no requirement due to practical reality. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [December 14, 2021, 12:30am UTC](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634/20 "2021-12-14T00:30:02Z")
> [@jvanasco](#): > > This means that when revoking a certificate for Domain A, if one marks it compromised, all other certificates that share the key must be revoked by the CA. Because this will have an effect on other certificates, the fix to Boulder/Pebble requires proof of controlling the private key when asserting that key is compromised. This fixes nothing. If human error is the reason why this bug is happening in the first place, how does this fix prevent a human from making this boo-boo, but now using the private key as revocation method? Perhaps statistically, boo-boos are 2 out of 3 times prevented just by accepting only 1 out of 3 possible methods.. But boo-boos are still possible.. [Next page](https://community.letsencrypt.org/t/question-re-change-in-revocations-methods/167634.md?page=2)