Thanks Yoav! I've already spoken with Jacob about this change offline, and plan to bring it up as part of my timeslot this week. You're absolutely right that it doesn't affect any of the bits on the wire; it's just instructions on client behavior. I'm in favor of incorporating this language (or a slightly edited version of it); I'm just unfamiliar with the process for incorporating changes like this as we move out of WGLC and into IESG.
Aaron On Mon, Nov 4, 2024 at 12:34 PM Yoav Nir <ynir.i...@gmail.com> wrote: > Thanks for that. > > If I’m reading this correctly, this is all clarification, not > bits-on-the-wire changes. Changes like that can be added after WGLC if they > don’t raise objections. > > I see that you are not registered for the IETF meeting, so it probably > doesn’t make sense to discuss it at the ACME session, but we’ll mention > that the PR exists, and the discussion can continue on the mailing list. > > Yoav > > On 29 Oct 2024, at 22:09, Jacob Hoffman-Andrews <jsha= > 40letsencrypt....@dmarc.ietf.org> wrote: > > Hi all, and especially to Yoav and Aaron for getting the ARI draft through > Last Call. > > I'm very sorry to make a substantive proposal _after_ Last Call, but after > talking to a client author I became concerned that we're not being explicit > enough about how frequently clients should check. I've just uploaded this > PR: > > https://github.com/aarongable/draft-acme-ari/pull/82 > > For convenience, I'm reproducing the added sections below: > > ## Schedule for checking RenewalInfo objects > > RenewalInfo objects must be fetched frequently so that clients learn about > renewal quickly. But requests must not overwhelm the server. This protocol > uses the Retry-After header to indicate to clients how often to retry. Note > that in other HTTP applications, Retry-After often indicates the earliest > time to retry a request. In this protocol, it indicates both the earliest > time and a target time. > > Clients SHOULD fetch a certificate's RenewalInfo object immediately after > issuance. After that, clients SHOULD fetch the certificate's RenewalInfo as > soon as possible after the time indicated in the Retry-After header > (backoff on errors takes priority, though). Clients SHOULD set reasonable > limits on the value in the Retry-After header. For instance, values under 1 > minute should be treated as if they were one minute and values over one day > should be treated as if they were one day. > > Clients SHOULD stop checking RenewalInfo after a certificate is expired. > Clients SHOULD stop checking RenewalInfo after they consider a certificate > to be replaced (for instance, after a new certificate for the same > identifiers has been received and configured). > > ### Error handling > > Temporary errors include, for instance: > > - Connection timeout > - Request timeout > - 5xx HTTP errors. > > On receiving a temporary error, clients SHOULD do exponential backoff with > a capped number of tries. If all tries are exhausted, clients SHOULD treat > the request as a long-term error. > > Long term errors include, for instance: > > - Retry-After is invalid or not present > - RenewalInfo object is invalid > - DNS lookup failure > - Connection refused > - Non-5xx HTTP error > > On receiving a long term error, clients SHOULD perform the next > RenewalInfo fetch as soon as possible after six hours have passed (or some > other locally configured default). > > ### Server choice of Retry-After > > Servers set the Retry-After header based on their requirements on how > quickly to perform a revocation. For instance, a server that needs to > revoke certificates within 24 hours of notification of a problem might > choose to reserve twelve hours for investigation, six hours for clients to > fetch RenewalInfo, and six hours for clients to perform a renewal. Setting > a small value for Retry-After means that clients can respond more quickly, > but also incurs more load on the server. Servers should estimate their > expected load based on the number of clients, keeping in mind that third > parties may also monitor RenewalInfo endpoints. > _______________________________________________ > Acme mailing list -- acme@ietf.org > To unsubscribe send an email to acme-le...@ietf.org > > > _______________________________________________ > Acme mailing list -- acme@ietf.org > To unsubscribe send an email to acme-le...@ietf.org >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
