During regular PMA review of our CP/CPS we noted that Section 4.9.12 stated that “Successful revocation requests with a reason code of keyCompromise will result in the affected key being blocked for future issuance and all currently valid certificates with that key will be revoked.” However, this does not accurately describe Let’s Encrypt’s behavior.
The ACME protocol supports three different kinds of revocation requests: those signed by the ACME account key of the Subscriber who originally requested the certificate, those signed by the ACME account key of a different Subscriber who has demonstrated control over all identifiers in the certificate, and those signed by the keypair represented by the certificate itself. Only the last of these actually demonstrates that the key has been compromised, and so we only block the key and revoke other certificates sharing that key when the revocation request was signed by the certificate key itself. This behavior was and remains a deliberate choice, to prevent a potential DoS vector.
We have changed the language in our CP/CPS to reflect our actual behavior, and have filed an incident to reflect the period of time in which our behavior was in violation of our CPS. You can follow that bug for updates.