On Mon, Jul 03, 2023 at 07:32:15AM -0400, Deb Cooley wrote: > We are happy to have more participation in the acme working group. The > IETF is based on development of standards by rough consensus. If you are > willing to roll up your sleeves and participate (by reviewing/commenting on > the drafts, and contributing to discussion) we are happy to have you. It > is not called the 'acme server' working group. The working group is only > as sleepy as we make it. > > I will say that reading pages of a single message serves only to bury the > lead. Crafting opinions that are clear and concise get quicker results. > We are all busy people.
Thinking about that message, the following occured to me: Is there need for there to be range of renwal times, as opposed to just a single time? The client needs to randomly pick a time anway, and do that either deterministically, or store the time, because doing repeated random checks is biased. Instead, the CA could be doing the randomization, maybe even avoiding times of predictable load spikes (top of hour, and especially all balls). And secondarily, there does not seem to be any guidance when it is appropriate to use the explanation link. It is probably not a good idea to use it for routine renews, or even maintenance avoidance (due to amount of noise generated). > On Fri, Jun 23, 2023 at 1:44 PM Michael Sweet <msweet= > 40msweet....@dmarc.ietf.org> wrote: > > > In a somewhat-related situation for printing, we have an event > > notification interface (RFC 3996) where the printer can report back a time > > interval (in seconds) when the client should re-contact the printer to get > > more events. This is flexible enough to handle both printer/server load > > and to let the client now when it should anticipate more events, i.e., the > > printer is printing something, the event subscription is for > > 'job-completed', and the printer can estimate when the print job will > > complete - this is analogous to an ACME certificate's expiration/renewal > > date/time. The problem is that the renew time can change, and always do so in response to unforeseen events. > > Personally, the servers I maintain use Let's Encrypt and have a weekly > > cron job that checks whether the server's certificate needs to be renewed. > > If the ACME server could provide a "retry after" response then my servers > > (ACME clients) could do a better job of scheduling the next update and not > > bug the ACME server so often... That is way too rarely for dealing with revocation. For that, you would need twice a day at very least. The ACME client I wrote checks 8-9 times a day by default... As for load caused by that, webhooks have usability issues, but I suspect polling would cause high load for for huge integrators. 3 times a day with 50k certs would be ~1.7rps just from ARI. Hmm... How much load would ARI cause for Let's Encrypt if everyone used ARI? Let's do back of the envelope calculation: - ~270M active certificates. - ~180M are unreplaced. - ~540M checks with 3 checks per day. - ~6250 rps. Which should be fine even without CDN. I suspect that "50k integrator" with single-threaded ACME client case would be much nastier. Replacing all the certs at 1das per cert would would take 500ks, which is longer than the 5 day deadline for revocation (and screwing up DV is 1 day revocation). (And making concurrent ACME is not trivial, due to order-order and name-name race conditions.) -Ilari _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
