Subject: [Acme] The ACME Renewal Information (ARI) extension

From: Aaron Gable <[email-masked]>
Date: Fri, 20 Aug 2021 17:34:38 -0700

Hello all,

In March of 2020, Roland Shoemaker started a conversation[1] on this list
regarding a potential new ACME extension, the ACME Renewal Information
(ARI) API. The goal of this extension is to allow ACME servers to provide
hints to ACME clients about when they should renew the certificates they
are responsible for.

[1] https://mailarchive.ietf.org/arch/msg/acme/b-RddSX8TdGYvO3f9c7Lzg6I2I4/

The purpose of this message is to restart this conversation. It is my (and
Let’s Encrypt’s) intention to draft, design, implement, and standardize
something to fulfil this role in the ACME ecosystem.

I have already begun work on the text of an Internet Draft based on
Roland’s initial proposal. I hope to have that ready to share in the next
week. At IETF 111 we discussed having an interim virtual ACME WG meeting in
mid-late September. It is my goal to present the draft at that meeting. If
that meeting does not occur, then I will present at IETF 112.

As part of moving this conversation forward, I’d like to directly address
some of the comments raised by Matt Holt[2] and Andrew Ayer[3] on the
original proposal.

[2] https://mailarchive.ietf.org/arch/msg/acme/kSm_atiR9ageSoEheNp6xYyJZOU/
[3] https://mailarchive.ietf.org/arch/msg/acme/szDHa5z6qRiAtmeC2ohrePPoBjU/

-----

On Tuesday, 24 March 2020, Matt Holt <[email-masked]> wrote:
> In terms of trust, what is the difference between knowing a certificate
is going to be revoked soon, and a certificate that is already revoked? In
a binary sense, if you know a certificate is going to be revoked, it's as
good as revoked. Why should you continue to trust a certificate when the CA
already knows it shouldn't continue to be trusted?
> ...
> Before going too deep into implementation details, I think the
philosophical paradox this proposal introduces should be resolved.

The purpose of this proposal is not to inform clients that their
certificate is about to be revoked; rather, the purpose is to inform
clients of a window in which it would be good for them to renew their
certificate. This can be used in many scenarios: spreading out clients
whose certificates have clustered `notAfter` timestamps; ensuring that a
client doesn’t miss that their current certificate has a validity period
different from that which it normally expects (e.g. if a CA switched from
90-day to 30-day certs, renewing 30 days before expiration would suddenly
be a mistake); accelerating the timeframe in which certificates issued by a
valid-but-undesirable intermediate rotate out of circulation; or hinting to
a client that its certificate might be revoked soon and should be replaced
prior to that event.

In particular, one of the most critical applications of this proposal is
not for the event of a mass revocation, but rather to manage the fallout of
such an event. If a CA were to revoke and replace a significant number of
certificates in a 24-hour period, then they will experience an ongoing
“thundering herd” problem every few days/weeks/months (depending on their
standard validity period) thereafter. ARI could be used to hint to some
clients that they should wait the maximum possible time before renewing,
while others could be directed to renew immediately, immediately mitigating
the thundering herd problem.

As such, data communicated by the ARI API should not be taken to mean “this
certificate is going to be revoked soon”, and does not communicate trust
information.

-----

On Tuesday, 24 March 2020, Matt Holt <[email-masked]> wrote:
> In my opinion, the burden is on the clients to just be a little more
fault-tolerant. They should staple OCSP responses. They should do so
conservatively. They can call `renewCert()` when they see a Revoked
response.

Unfortunately, this approach only works for ACME clients that are
themselves also web servers, and are therefore capable of stapling an OCSP
response to a TLS handshake. Many clients are only responsible for
populating a certificate on disk, not responsible for providing that
certificate to TLS clients, and so cannot guarantee things like stapling.

In addition, this approach does not handle the load-smoothing case
discussed above.

-----

On Tuesday, 24 March 2020, Andrew Ayer <[email-masked]> wrote:
> I think it would be really useful if the renewal information could be
discovered and retrieved by third parties.  This would permit monitoring
services to raise an alarm if a certificate is going to be revoked soon,
just in case the automation fails to renew it (or there is no automation,
which is unfortunately common).  For example, during the recent Let's
Encrypt revocation incident, Cert Spotter used the list of serial numbers
published by Let's Encrypt to alert the users of Cert Spotter who were
affected.

This sounds to me like a point in favor of having the proposal specify how
the renewalInfo url is constructed, such that clients don’t have to cache
it on-disk, and such that it could be constructed by third parties as well.

Notably, RFC 8555 does not specify how to construct Certificate URLs. As
per spec, the url from which to download a certificate can only be
determined by examining the corresponding Order (which can only be loaded
by the Subscriber that created the Order) and loading the Certificate URL
contained in that resource. Given that there is no
third-party-constructable way to fetch certificates from an ACME, it would
feel odd to me for there to be consistent third-party-constructable ways to
fetch certificate renewal info.

(It is open knowledge that Let’s Encrypt constructs certificate URLs by
concatenating the original and creative “/acme/cert/” prefix with the
hex-encoded certificate Serial number, and we have taken advantage of that
fact to provide affected certificate details in incident reports, but that
is not standardized.)

----

Thank you all for your thoughtful comments a year ago, and I look forward
to more discussion and sharing my draft in the near future.

Aaron