Consider a "This has been renewed" endpoint

[aarongable]

One of the use-cases for ARI is being able to inform clients that they should renew ASAP, because the CA intends to revoke their certificate in the near future and would like to help the client avoid a service interruption.

In this case, it would be helpful for the CA to know when a client considers a cert to have been renewed (which may involve several newOrder and Finalize requests, in the case of validation/issuance failures, or certs with many identifiers having those identifiers shuffled between them) so that the cert can be safely revoked.

Sketch:

POST /acme/renewal-info/<issuer-key-hash>/<issuer-name-hash>/<serial> HTTP/1.1
Host: example.com
Content-Type: application/jose+json

{
  "protected": base64url({
    "alg": "ES256",
    "jwk": {...},
    "nonce": "6S8IqOGY7eL2lsGoTZYifg",
    "url": "https://example.com/acme/renewal-info/<issuer-key-hash>/<issuer-name-hash>/<serial>"
  }),
  "payload": base64url({
    "renewed": true,
  }),
  "signature": "RZPOnYoPs1PhjszF...-nh6X1qtOFPB519I"
}

[jesperkristensen]

This seems similar to if the client revokes the certificate with reason code "superseded" using the existing ACME endpoint. So why is a new endpoint needed?

Arguments against always revoking may be that the certificate could be still in use by the time the ACME client thinks renewal is complete, because of eventual consistency. Or because the certificate may be later restored from a backup. But those concerns would apply to this new renewed endpoint as well.

I guess the new endpoint allows the CA more flexibility in choosing when to revoke based on a risk vs. reward trade-off.

Would Let's Encrypt consider not sending renewal reminder emails for certificates that are marked as renewed using this API?

[aarongable]

Ooh that's a really good point; I'd forgotten about the "superseded" reason code. That may be all that's necessary here -- it is the same number of total requests to the ACME server, accomplishes the goal of revocation, and provides a clear indication of why revocation happened. It is less flexible than the new API proposed above, which would allow a CA to decide when and whether to revoke. But honestly maybe encouraging the whole ecosystem to move to "renew then revoke" in all circumstances is a good thing.

I think concerns about eventual consistency are valid. In particular, there may be clients which are concerned about exactly that, and so choose to never revoke the recently-replaced cert. And that model would be fine in most circumstances... until a mass revocation event happens and the CA doesn't know when it is "okay" to revoke the old cert.

Yes, today LE has to decide whether or not to send a renewal reminder based on a very rough heuristic. If confirmation of renewal existed -- either in the form of the proposed new API call, or in the form of the old cert being revoked as superseded -- that heuristic could be greatly improved.