If you have any questions regarding the announcement below, feel free to ask and discuss them here. [image] Upcoming changes to revocation reasons API Announcements D…

[image] Upcoming changes to revocation reasons 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 , only requests authenticated using the certificate's private key could …

Everything @aarongable mentioned in the news posting noted this clause: [image] Upcoming changes to revocation reasons 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 …

[image] 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 Subsc…

[image] 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 "cessationOfOperatio…

[image] 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 certifica…

[image] 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

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 als…

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.

[image] 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 sp…

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 equivalent to proof of control over a private key: MRSP 6.1.1 End Entity TLS Certificate CRLRevocation Rea…

Questions re: Upcoming changes to revocation reasons

Issuance Policy

jvanasco August 17, 2022, 5:56pm 10

See What could Let’s Encrypt do to make client dev easier? - #24 by petercooperjr

Topic		Replies	Views
Question re: Change in Revocations Methods Issuance Policy	52	3917	January 15, 2022
Upcoming changes to revocation reasons API Announcements	1	1583	September 21, 2022
'JWS verification error' trying to revoke a certificate Client dev	23	4288	December 14, 2021
Certificate Revoke Error. The request message was malformed :: No such certificate Help	18	3590	October 19, 2018
Reason for Revokation of 1076742682.rsc.cdn77.org Issuance Policy	27	9039	May 11, 2016

Questions re: Upcoming changes to revocation reasons

Related topics