# Questions re: Upcoming changes to revocation reasons **URL:** \ **Category:** Issuance Policy\ **Created:** [August 16, 2022, 11:35pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954 "2022-08-16T23:35:13Z")\ **Posts on this page:** 20\ **Page:** 1
**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:** [August 16, 2022, 11:35pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/1 "2022-08-16T23:35:13Z")
If you have any questions regarding the announcement below, feel free to ask and discuss them here. > [@Upcoming changes to revocation reasons](https://community.letsencrypt.org/t/upcoming-changes-to-revocation-reasons/182953): > > D… ---
**Author:** ![dtaylor84](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@dtaylor84](https://community.letsencrypt.org/u/dtaylor84)\ **Post date:** [August 16, 2022, 11:52pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/2 "2022-08-16T23:52:22Z")
1. How does signing a revocation request with the certificate private key "demonstrate a compromise" of that key? How is it different from the private key being used by a web server to establish a TLS session with a browser? 1. "All requests for revocation which are authenticated using the key of a Subscriber who did not originally order the certificate, but who has demonstrated control over all names in that certificate" vs later "So we will interpret a request of this kind as "evidence that the certificate subscriber no longer controls, or is no longer authorized to use, all of the domain names in the certificate", and use the reason "cessationOfOperation" instead." Should one of "all names" / "all of the domain names" say "any" rather than "all"? ---
**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:** [August 17, 2022, 12:00am UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/3 "2022-08-17T00:00:48Z")
> [@dtaylor84](#): > > 1. How does signing a revocation request with the certificate private key "demonstrate a compromise" of that key? > > How is it different from the private key being used by a web server to establish a TLS session with a browser? We have no way to know who made the request to revoke -- all we know is that the request was signed using the certificate's private key. Whoever is making the request to revoke wants us to know that they control the private key. Therefore we must assume that it has been compromised. Obviously yes, this assumption is faulty. There are many situations in which the original Subscriber makes a request to revoke the cert and uses the cert's private key instead of their own Subscriber key to authenticate that request (heck, there are some ACME clients which _always_ use this method to request revocation, regardless of the reason). But from the ACME server side, we have no way to know, so it behooves us to assume the worst. > [@dtaylor84](#): > > Should one of "all names" / "all of the domain names" say "any" rather than "all"? No, revocation via this authentication mechanism only works when the requesting Subscriber who [controls _all_ of the names](https://www.rfc-editor.org/rfc/rfc8555.html#section-7.6) in the certificate in question. ---
**Author:** ![maxh](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/maxh/32/31936_2.png) [@maxh](https://community.letsencrypt.org/u/maxh)\ **Post date:** [August 17, 2022, 3:58am UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/4 "2022-08-17T03:58:17Z")
> [@aarongable](#): > > Therefore we must assume that it has been compromised. I'm not sure why that assumption must be made. Mozilla requires overwriting the requested reason only when there is verifiable evidence of compromise. The fact that _someone_ has the key does not demonstrate compromise. If anything, the fact that a revocation request is being submitted with a different (or no) reason is evidence _against_ key compromise. > [@](#): > > No, revocation via this authentication mechanism only works when the requesting Subscriber who [controls _all_ of the names](https://www.rfc-editor.org/rfc/rfc8555.html#section-7.6) in the certificate in question. That reads to me as though a subscriber who controls all names _must_ be allowed to revoke the certificate, but it does not rule out allowing a subscriber who controls some incomplete subset to do so. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [August 17, 2022, 6:08am UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/5 "2022-08-17T06:08:14Z")
> [@Upcoming changes to revocation reasons](https://community.letsencrypt.org/t/upcoming-changes-to-revocation-reasons/182953/1): > > 1. Requests for revocation which are authenticated using the key of the Subscriber who originally ordered the certificate will be able to request reason "keyCompromise". [Previously](https://community.letsencrypt.org/t/change-in-revocation-methods-due-to-a-now-patched-acme-bug/167633), only requests authenticated using the certificate's private key could request this reason. **However, requests for revocation with reason "keyCompromise" but which do not _demonstrate_ said compromise will not result in the key being blocklisted from future issuance, nor result in all other certificates which share that key also being revoked for the same reason.** I'm not sure this is allowed in the current baseline requirements? 4.9.1.1 item 3 states: > 1. The CA obtains evidence that the Subscriber’s Private Key corresponding to the > Public Key in the Certificate suffered a Key Compromise; If I revoke my cert with `keyCompromise`, how is that _not_ "evidence"? The BR do not state I need to "demonstrate" controle over the key. It just states "evidence". And I think the revocation reason `keyCompromise` is evidence enough? ---
**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:** [August 17, 2022, 3:37pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/6 "2022-08-17T15:37:07Z")
Everything @aarongable mentioned in the news posting noted this clause: > [@Upcoming changes to revocation reasons](https://community.letsencrypt.org/t/upcoming-changes-to-revocation-reasons/182953/1): > > regardless of the requested reason. For Client Developers, does that mean we generally do not need to worry about updating our clients in the foreseeable future, and it will be acceptable for quite some time to submit an inapplicable/alternative reason (even though LetsEncrypt will ignore it and log the reason in accordance with these new guidelines)? Past actions by ISRG and the goal of continuous automated renewals lead me to believe this interpretation is correct, but I'd like to be sure no actions by developers are necessary. ---
**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:** [August 17, 2022, 4:39pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/7 "2022-08-17T16:39:11Z")
> [@maxh](#): > > That reads to me as though a subscriber who controls all names _must_ be allowed to revoke the certificate, but it does not rule out allowing a subscriber who controls some incomplete subset to do so. This is correct. However, we have a long-standing policy of not allowing a Subscriber who controls only _some_ of the names on a certificate to revoke that certificate -- doing so effectively leads to denial of service attacks. That policy is not changing. > [@Osiris](#): > > If I revoke my cert with `keyCompromise`, how is that _not_ "evidence"? Recall that a Subscriber is not required to prove control over the private key corresponding to the public key in the certificate that they order. So it is possible that a malicious Subscriber could observe the public key in a target's certificate, request their own certificate containing the same public key, and then revoke their own certificate with reason keyCompromise. Under your interpretation, this would require us to revoke the target's certificate as well, even though its private key has not actually been compromised. This is a denial of service attack, and this is why we require that the revoker _demonstrate_ control over the private key in order for the revocation to propagate to other certificates that share the same key. > [@jvanasco](#): > > For Client Developers, does that mean [...] it will be acceptable for quite some time to submit an inapplicable/alternative reason [...]? Yes. Although we do completely reject revocation requests for inapplicable reasons (such as "cACompromise", which a Subscriber is not allowed to assert), revocation requests for all of the allowed reasons ("unspecified", "keyCompromise", "superseded", and "cessationOfOperation") will continue to succeed, with the reason code silently overwritten if necessary. ---
**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:** [August 17, 2022, 4:52pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/8 "2022-08-17T16:52:58Z")
> [@aarongable](#): > > Yes. Although we do completely reject revocation requests for inapplicable reasons (such as "cACompromise", which a Subscriber is not allowed to assert), revocation requests for all of the allowed reasons ("unspecified", "keyCompromise", "superseded", and "cessationOfOperation") will continue to succeed, with the reason code silently overwritten if necessary. Wonderful! Thank you! ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [August 17, 2022, 5:44pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/9 "2022-08-17T17:44:22Z")
> [@aarongable](#): > > Recall that a Subscriber is not required to prove control over the private key corresponding to the public key in the certificate that they order. So it is possible that a malicious Subscriber could observe the public key in a target's certificate, request their own certificate containing the same public key, and then revoke their own certificate with reason keyCompromise. Under your interpretation, this would require us to revoke the target's certificate as well, even though its private key has not actually been compromised. This is a denial of service attack, and this is why we require that the revoker _demonstrate_ control over the private key in order for the revocation to propagate to other certificates that share the same key. I'm now wondering which grounds of the BR mandate a CA to revoke _all_ certificates with a certain public key when the private key has been leaked. If that ground is _also_ 4.9.1.1 sub 3, then the BR do not require _demonstration_ of the leakage, but _evidence_ is enough. Also, how would you be able to issue a certificate with a certain public key, if you don't have the private key? AFAIK the CSR needs to be signed with the private key and this is checked by the CA. Although technically I can't see this requirement in the BR 🙄 Maybe my searc-FU isn't good enough _or_ it isn't required.. ---
**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:** [August 17, 2022, 5:56pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/10 "2022-08-17T17:56:23Z")
> [@Osiris](#): > > Also, how would you be able to issue a certificate with a certain public key, if you don't have the private key? See [What could Let’s Encrypt do to make client dev easier? - #24 by petercooperjr](https://community.letsencrypt.org/t/what-could-let-s-encrypt-do-to-make-client-dev-easier/178103/24) ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [August 17, 2022, 6:00pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/11 "2022-08-17T18:00:05Z")
Yes, it's possible, as apparently the signing of a CSR with the private key or other proof of posession of the private key isn't mandated by the BR, but LE _does_ mandate it by only allowing self-signed CSRs. So while not _always_ the case, in the case of LE, getting a cert with a certain public key also requires access to the accompanying private key. Therefore, still in at least the case of LE, the denial of service attack mentioned by @aarongable isn't viable. ---
**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\ **Post date:** [August 17, 2022, 6:11pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/12 "2022-08-17T18:11:43Z")
Yeah, I'm with @Osiris on this as well. I'm guessing the scenario they're trying to consider is one where an "attacker" has a CSR but not the private key itself, which is in theory possible since CSRs only have "public" information so they might get "leaked" more readily. Or something like that. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [August 17, 2022, 6:23pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/13 "2022-08-17T18:23:30Z")
> [@petercooperjr](#): > > I'm guessing the scenario they're trying to consider is one where an "attacker" has a CSR but not the private key itself, which is in theory possible since CSRs only have "public" information so they might get "leaked" more readily. But the CSR would also include the specific hostname(s), so that's no dice in almost certainly ever circumstance. It's almost impossible to have the possibility to validate random hostnames and it would be a heck of a coincidence you just happen to have controle over the hostname somehow. Modyfing the CSR would also invalidate the signature (at least now that SHA-1 is forbidden 😛) ---
**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:** [August 17, 2022, 6:24pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/14 "2022-08-17T18:24:11Z")
CSRs are not considered private information, and are frequently posted online (including in this support forum!) or left somewhere visible to the public. Possession of a CSR is [explicitly not](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation:~:text=A%20CSR%20alone%20does%20not%20prove%20possession%20of%20the%20certificate%E2%80%99s%20private%20key%20for%20the%20purpose%20of%20initiating%20a%20revocation.) equivalent to proof of control over a private key: > **MRSP 6.1.1 End Entity TLS Certificate CRLRevocation Reasons: keyCompromise** > A CSR alone does not prove possession of the certificate’s private key for the purpose of initiating a revocation. A very common circumstance is the purchase of a domain name. Suppose that someone owns thousands of domains, and uses the same key in all of the individual certs for every domain that they own. Suppose further that I purchase one of those domains from them. Then I could copy their CSR for that domain, request issuance using that CSR, revoke my own cert for reason keyCompromise, and thereby revoke all of their other certificates. ---
**Author:** ![Bruce5051](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruce5051/32/76576_2.png) [@Bruce5051](https://community.letsencrypt.org/u/Bruce5051)\ **Post date:** [August 17, 2022, 6:55pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/15 "2022-08-17T18:55:02Z")
> [@aarongable](#): > > CSRs are not considered private information, and are frequently posted online (including in this support forum!) or left somewhere visible to the public. Possession of a CSR is [explicitly not](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation:~:text=A%20CSR%20alone%20does%20not%20prove%20possession%20of%20the%20certificate%E2%80%99s%20private%20key%20for%20the%20purpose%20of%20initiating%20a%20revocation.) equivalent to proof of control over a private key: As I understand a CSR is just a Public Key plus some meta data that the CA signs and returns as Certificate that has the Public Key and more meta data (and some meta data 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:** [August 17, 2022, 7:13pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/16 "2022-08-17T19:13:59Z")
Approximately correct. They are just a public key plus some metadata, but hopefully the CA doesn't just sign it and return it as a certificate -- that way lies misissuance 🙂 For Let's Encrypt's purposes, they're essentially just a transport format for a public key. The only other pieces we care about are the must-staple extension and ensuring that the list of names matches the original order, but neither of those is carried directly into the final certificate. ---
**Author:** ![Bruce5051](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruce5051/32/76576_2.png) [@Bruce5051](https://community.letsencrypt.org/u/Bruce5051)\ **Post date:** [August 17, 2022, 7:41pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/17 "2022-08-17T19:41:42Z")
> [@aarongable](#): > > that way lies misissuance 🙂 Obviously, I was only referring to the content of the CSR and Cert. Not the certification process itself. ---
**Author:** ![dtaylor84](https://avatars.discourse-cdn.com/v4/letter/d/ee7513/32.png) [@dtaylor84](https://community.letsencrypt.org/u/dtaylor84)\ **Post date:** [August 18, 2022, 2:33pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/18 "2022-08-18T14:33:59Z")
> [@aarongable](#): > > No, revocation via this authentication mechanism only works when the requesting Subscriber who [controls _all_ of the names](https://www.rfc-editor.org/rfc/rfc8555.html#section-7.6) in the certificate in question. Sorry, what I meant was, the current wording seems contradictory. Although re-reading, maybe it's just ambiguous. > [@A](#): > > All requests for revocation which are authenticated using the key of a Subscriber who did not originally order the certificate, but who has demonstrated control over all names in that certificate > [@B](#): > > So we will interpret a request of this kind as "evidence that the certificate subscriber no longer controls, or is no longer authorized to use, all of the domain names in the certificate I read A as referring to non-original subscribers who demonstrate control over **all** names. (easy) But I read B as referring to original subscribers who no longer control all of the names. To me, that means 'who controls none, or some, but not all, of the names' rather than the implied opposite of A, which would be 'who controls none of the names'. (Or, using wording closer to the original, 'who no longer controls, or is no longer authorized to use, **any** of the domain names in the certificate.') ---
**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:** [August 18, 2022, 2:56pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/19 "2022-08-18T14:56:33Z")
I can see how this can be confusing. I've spend too much time on Patents, so maybe this slight edit of @aarongable's text is more clear: > All requests for revocation which are authenticated using the key of a Second Subscriber, who did not originally order the certificate but who has demonstrated control over _all_ names in that certificate, will result in the certificate being revoked with reason "cessationOfOperation", regardless of the requested reason. This is because the new requirements state that the various allowed revocation reasons MUST only be used when the CA has a specific reason to use them (as with "keyCompromise" above) or when the certificate’s Subscriber (the First Subscriber) requests them. But in this case, someone other than the certificate Subscriber (the First Subscriber) is requesting revocation - the Second Subscriber is. So we will interpret a request of this kind as "evidence that the certificate subscriber no longer controls, or is no longer authorized to use, all [each and every one of] of the domain names in the certificate", and use the reason "cessationOfOperation" instead. ---
**Author:** ![maxh](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/maxh/32/31936_2.png) [@maxh](https://community.letsencrypt.org/u/maxh)\ **Post date:** [August 19, 2022, 8:05pm UTC](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954/20 "2022-08-19T20:05:08Z")
> [@aarongable](#): > > However, we have a long-standing policy of not allowing a Subscriber who controls only _some_ of the names on a certificate to revoke that certificate -- doing so effectively leads to denial of service attacks. Is there an explanation somewhere for how that would work? [Next page](https://community.letsencrypt.org/t/questions-re-upcoming-changes-to-revocation-reasons/182954.md?page=2)