Due to upcoming requirements regarding revocation in the latest version of the Mozilla Root Store Policy, we will be making a number of small changes to the way that ACME API requests for revocation are handled.
As background information, ACME clients can authenticate a revocation request in any of three ways. First, they can authenticate the request using the key of the Subscriber who originally requested the to-be-revoked certificate (this allows Subscribers to revoke their own certificates, as one would expect). Second, they can authenticate the request using the key of a different Subscriber, but one who has demonstrated control over all DNS names in the certificate (this allows a Subscriber who has purchased a domain name to revoke certificates issued to the previous owner). Third, they can authenticate the request using the private key of the certificate itself, proving that they have access to the certificate private key.
As additional background information, when a certificate is revoked, the revoker can also supply a "reason". These reasons are selected from a short predefined and standardized list, and include reasons such as "keyCompromise", "superseded", and "unspecified", among others.
The changes are as follows:
-
All requests for revocation which are authenticated using the private key of the certificate itself will result in the certificate being revoked with reason "keyCompromise", regardless of the requested reason.
This is because use of the certificate private key for the purpose of authenticating an ACME API revocation request counts as a "demonstration of compromise", and the new requirements state that the CA MUST use reason "keyCompromise" when they "obtain verifiable evidence that the certificate subscriber’s private key... suffered a key compromise". -
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, 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 Subscriber requests them. But in this case, someone other than the certificate Subscriber is requesting revocation. 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. -
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 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.
This is because the new requirements state that the CA MUST use reason "keyCompromise" when "the certificate subscriber requests that the CA operator revoke the certificate for this reason". -
Finally, if a certificate has been previously revoked for any non-"keyCompromise" reason, and then we receive a demonstration of compromise (i.e. a revocation request signed with the certificate's private key) for that key, then we will update the revocation reason from its previous value to "keyCompromise".
This is because the new requirements state that when a CA "obtains verifiable evidence of private key compromise" for an already-revoked certificate, then "the CA operator SHOULD update the CRL entry to enter keyCompromise as the CRLReason".
These changes have already been made in our Staging environment, so you can test them there.
We will make the same changes in our Production environment on September 21st, 2022, to coincide with our update to the Subscriber Agreement.
You can read more about revoking certificates here. And as a reminder, we will be making two other changes (related to SHA-1 CSRs and TLS1.0/1.1) in mid-September as well. If you have questions about these changes, you can discuss them here.