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
