That makes sense. Of course, the specified URL construction couldn't be as simple as using the serial number, because serial numbers are not (as per the Baseline Requirements, and RFC 6960) guaranteed to be unique except within the context of a single Issuer, and an ACME CA may have multiple Issuers. So that means that the unique URL component would need to be something like the full certificate fingerprint, which is slightly more complex to construct.
And such a mechanism means that the ACME client needs to either make multiple HTTP requests (one for the directory, one for the renewalInfo) or cache the directory info (in which case it is also storing metadata on disk). I look forward to discussing this more tomorrow! Aaron On Thu, Sep 23, 2021 at 2:10 PM Andrew Ayer <[email protected]> wrote: > On Thu, 23 Sep 2021 09:39:24 -0400 > Andrew Ayer <[email protected]> wrote: > > > > 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. > > I received a comment off-list that mandating a URL format would run > afoul of BCP 190. > > Fortunately, that restriction was loosened in 2020 by RFC 8820, and it's > now acceptable for protocols to specify a URL structure as long as it's > under a path that the server is allowed to pick. > > For instance, it would be fine to specify that the ARI URL is > constructed by appending the certificate serial number to a URL > specified in the ACME directory. > > Regards, > Andrew > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
