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
