Question re: Change in Revocations Methods

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?



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.


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.


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.


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).



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. :pensive:


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.


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.


I can see an edge case as you've mentioned, @jvanasco, with centralized issuance. :eye:


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.


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".


We like to think of certs and keys as one-to-one, but there's no requirement due to practical reality.


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..


Ah, I can see it that way now too. But perhaps it's better to phrase it in such a way there can be no doubt about the intention of the sentence.


Essentially, yeah. It's not an iff situation. I thought the condition and effect were inverted.


So I can't revoke using the ACME account key with keyCompromise as the reason then?


No, you can't, for reasons I still don't understand.

A human made a boo-boo with very large consequences, but I have not seen any argumentation why the private key is the sole revocation method..


Correct. Revoking with the ACME account key proves that you are the Subscriber which requested the certificate, and the BRs require that CAs allow the Subscriber to revoke their own certs at any time.

However, the BRs only require that CAs revoke with reason keyCompromise (and therefore do the cascading revocation of all other certs with the same key) when key compromise has been demonstrated. Revoking using an ACME account key only proves control over that ACME account key, not over the certificate private key, so compromise has not been demonstrated.


Interestingly, BuyPass (last I checked) only supports revoking certs via ACME using the ACME Account key. So if they fix this bug, they effectively block everyone's ability to declare a key compromise (via ACME).

This is the ACME response when you try to revoke using the cert's private key:

{"type":"urn:ietf:params:acme:error:malformed","detail":"The key is unknown","code":400,"message":"MALFORMED_BAD_REQUEST","details":"HTTP 400 Bad Request"}

That fully clarifies the mystery. :face_with_monocle: