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 <m...@lightcodelabs.com> 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 <m...@lightcodelabs.com> 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 <a...@andrewayer.name> 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
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
