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 <g...@apnic.net> wrote: > A simpler sentence would be > > 'Allowing issuing CAs to suggest a period in which clients > should 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 has > chosen to use absolute (UTC) time rather than relative time, which means > that this > lack of unversal adherence to synchronised time is a consideration here > (an alternative > could've been to use time offsets relative to the time that the response > was generated, but > I 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 > measure > depends 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 <https://github.com/aarongable/draft-acme-ari/pull/90> pointing this out. > While the draft says: "If the selected time is in the past, attempt renewal > immediately.I" it is not clear to me that if the time provided by the > server > is ALWAYS in the future (because the client's local time is lagging UTC) > that the > algorithm described in the draft (the 6 steps) would allow the client to > simply 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
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
