Aaron Gable <aaron=40letsencrypt....@dmarc.ietf.org> wrote: > 1) Getting client to recheck ARI quickly and regularly
> This is tracked as https://github.com/aarongable/draft-acme-ari/issues/13 > The -01 ARI draft specifies that ARI responses must come with a > `Retry-After` header, and that clients should check ARI again after the > Retry-After period has passed. This matches the semantics of the > Retry-After header as specified in RFC7231. Agreed. > However, this does nothing to suggest that the client should check in again > as soon as possible after the retry-after period has passed. For example, a > cron-based ACME client that wakes up once every 24 hours would be fully > compliant with an ACME server whose Retry-After header specifies 6 hours. > We would like to have the document specify that clients should check in on > a regular, server-controlled basis. The ideas we've had so far are: I'm not quite clear how this can affect the once-every-24-hours crontab problem. Is it your contention that this behaviour would change? Would the client wake up once-every-24hours, and then wait? or that the crontab situation would change/go-away? > a) Include a "next check-in window" in the renewalInfo response, alongside > the existing suggestedWindow How big would these windows be? > b) Include a "polling period" in the server's directory (either by making > the new `renewalInfo` key map to an object with both the base url and the > polling period; or by including it as a new key in the directory's meta > object) I'm not sure I understand this option. > c) Another header? Is there another HTTP header that provides the semantics > we want? I don't think so. > d) Leave it as-in, and just specify that the client should check in within > a certain amount of time after the Retry-After header. > I'm currently leaning towards (b), including the polling period in the ACME > directory meta section, but am open to other ideas and discussion. That seems reasonable. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme