On Fri, 20 Aug 2021 17:34:38 -0700 Aaron Gable <aa...@letsencrypt.org> wrote:
> > 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. Correct. > 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. Could you elaborate on your concerns here? Is this purely an aesthetic concern or are there other problems with making the renewalInfo URL third-party-constructable? I'm not sure why it would be odd for this URL to be constructed differently from the certificate URL, as they serve different uses cases and have different needs. Another benefit of making the renewalInfo URL constructable is that it would reduce the effort required to add ARI to existing client implementations that don't currently persist any information on-disk besides the certificate chain and key (e.g. [1]). If the URL is constructable then adding ARI would be a more self-contained change compared to having to modify the storage system to allow additional data to be stored. I'm concerned that clients won't implement ARI because the perceived benefit to subscribers is minimal, since historically CAs have been willing to not revoke misissued certificates. To counteract this, it should be as easy as possible to add ARI to existing implementations. I reiterate my support for making the renewalInfo URL constructable using just the certificate. Regards, Andrew [1] https://cs.opensource.google/go/x/crypto/+/089bfa56:acme/autocert/autocert.go;l=512-545 _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
