Hi Geoff,
Thank you for the continued review! You've probably seen that I've published draft -07 incorporating most of your suggestions. Responses to your additional comments below.
On Mon, Nov 25, 2024 at 4:12 PM Geoff Huston <gih@xxxxxxxxx> wrote:
A simpler sentence would be
'Allowing issuing CAs to suggest a period in which clientsshould renew their certificates enables a form of CA load balancing."
(I don't think "dynamic time-based" actually adds enyting to the sentence!)
I'd prefer to keep the phrase "dynamic time-based" in this sentence, as it serves to distinguish the flavor of load-balancing from the more common flavor: spreading simultaneous requests across multiple servers in parallel.
A visible subset of end clients have a broken concept of the current time(see https://www.potaroo.net/ispcol/2018-11/time.html if you are interested). This specification haschosen to use absolute (UTC) time rather than relative time, which means that thislack of unversal adherence to synchronised time is a consideration here (an alternativecould've been to use time offsets relative to the time that the response was generated, butI suspect that this would have its own wrinkles as well!)
Indeed, using offsets / relative times would prevent ARI responses from being cached.
Some cautionary words that say that the load balancing properties of this measuredepends of a synchronised view of time, which is not assured.
I think that the number of ACME clients which disregard ARI suggestions due to clock skew will always be miniscule compared to the number of ACME clients which disregard ARI suggestions due to not having implemented ARI. But I've added a sentence to the paragraph in Security Considerations pointing this out.
While the draft says: "If the selected time is in the past, attempt renewalimmediately.I" it is not clear to me that if the time provided by the serveris ALWAYS in the future (because the client's local time is lagging UTC) that thealgorithm described in the draft (the 6 steps) would allow the client tosimply perform the renewal in any case at some point.
A reasonable server will never suggest a renewal window that is after the expiration of the certificate. If the client's clock is so skewed that the server's suggested window is still in the future even when the certificate expires, then ARI makes that client no worse off than it would have been before: it likely wouldn't have renewed until after its current certificate expired (from everyone else's perspective) anyway.
Thanks again,
Aaron
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
