Hello, I have a hard time deciding whether the proposal is a good idea or not, because the document does not contain sufficient information for me to make up my mind. In particular, I only see a problem statement and a solution proposal, but no reasoning on alternatives and why the proposal is the way to go.
This may be partly because I'm new to the list, but nevertheless, I think a document in general should present some arguments for its existence. (But I'm also happy with pointers to earlier messages on the list.) In particular, Section 1 states that clients renew certificates either a) at specific intervals, or b) a specific amount of time before the certificate's expiration, or c) when some percentage of the validity period has passed. I buy the argument that this causes problems with load spikes. Cases b) and c) may be alleviated more easily (in particular: with no client-side complexity, no protocol change, and no extra GET requests to the server), by smearing the certificate validity period, at issuance, randomly across 1%, e.g. between 100% and 101%, or between 99% and 100%. As a result, renewals would be attempted at random times of the day if the validity is at least ~3 months. In general, that is achieved if the smearing is designed to cover a full day. (This is assuming common web PKI validity periods. For very short-lived (~days) certificates, one would have to discuss whether such smearing would be too large a fraction of the total period.) Renewal timing could be randomized on the client side as well. This would also cover case a). While requiring a client upgrade, the ARI proposal does so as well. If it is expected that clients will be sufficiently upgrade-able in order to get ARI deployed, then what is the reasoning that the same thing can't be achieved with client-side smearing? I know that some clients do randomize, and it seems like that has not been successful, otherwise we wouldn't have this draft. Is that the case? Why? (And we should we have higher hopes for succeeding with ARI support on the client side?) IMHO, the proposal demands rather high cost (client-side change, server-side change, protocol change, extra requests). Having some arguments why it is worth it will make it much easier to decide whether it should be adopted or not. Best, Peter On 5/24/22 13:30, Deb Cooley wrote:
There has been some discussion of draft-aaron-acme-ari-02 on the mail list, at working group meetings, and the technical concerns have been addressed. Should the ACME WG adopt “Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension” in draft-aaron-acme-ari-02? Please reply to this message within the next two weeks, by Tuesday, 7 June 2022 to voice your support or opposition to adoption. On behalf of the ACME WG Chairs, Deb Cooley _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
-- https://desec.io/ _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
