If a certificate was detected to be mis-issued after the fact, it may need to be revoked. And in fact many certificates may need to be revoked. This has happened to Let's Encrypt a few times already, and was the main motivation for this API. Some existing systems like the Caddy server use OCSP to detect if a cert is revoked and can renew immediately, but ARI allows allows a certificate to be reissued before the old one is revoked.

There are other related things that aren't specifically revocation: For example, certificates contain embedded Certificate Transparency timestamps from CT logs. If one or more of those logs fail, we might want to reissue those certificates before browsers distrust the logs.

(I work for Let's Encrypt)

> Some existing systems like the Caddy server use OCSP to detect if a cert is revoked and can renew immediately, but ARI allows allows a certificate to be reissued before the old one is revoked.

Hi Matthew :)

Caddy still serves a perfectly valid "GOOD" response from the OCSP responder while it renews the certificate, so the certificate is good as not-revoked until that OCSP staple expires.

(As we know, revocation is broken anyway. We should deprecate it for public PKI and go with short cert lifetimes instead.)

Any CA can revoke a certificate they issued without the subscriber being involved, so subscribers aren't necessarily revoking their own certs. When that happens ARI is a more efficient automated mechanism by which to let people know that a revocation is coming and they should renew.

When revoking a certificate it gives peace of mind that whatever system is using that certificate will pull a new one.