Discussion thread for Change in Revocation Methods Due to a (now patched) ACME bug
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.
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).
3 Likes
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!
7 Likes
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.
4 Likes
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.
3 Likes
The potentially supported reason codes are defined in RFC5280 Section 5.3.1. Though I don't believe Boulder or any ACME CA currently accepts all of these.
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) }
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.
5 Likes
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?
4 Likes
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.
3 Likes
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.
4 Likes
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.
6 Likes
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).
4 Likes
?
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 supports the confusion:
That statement makes no mention of the ACME account key at all. I think it should.
Exactly my concern. Of course, the ACME account key sitting on that server is likely compromised right along with the certificate private key. 
4 Likes
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.
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.
5 Likes
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.
5 Likes
I can see an edge case as you've mentioned, @jvanasco, with centralized issuance. 
3 Likes
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.
4 Likes
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".
8 Likes
We like to think of certs and keys as one-to-one, but there's no requirement due to practical reality.
3 Likes
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..
5 Likes