Thanks for the clarification! We'll discuss Jacob's proposed language in the session on Wednesday, and I'll plan to issue draft -07 shortly after the document freeze is over.
Aaron On Mon, Nov 4, 2024, 21:47 Deb Cooley <debcool...@gmail.com> wrote: > Aaron, > > You can issue a new version of the draft, even as it sits in my queue. > I'd prefer you do that before I start my review. > > Deb > > On Mon, Nov 4, 2024 at 11:18 PM Aaron Gable <aaron= > 40letsencrypt....@dmarc.ietf.org> wrote: > >> 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 >> >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
