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
