I believe this erratum should be rejected, for a few reasons: 1) It is not a clarification or fixing an obvious mistake, it is a change to the protocol. Today, many ACME servers (Let's Encrypt included) immediately move an Authorization to the "invalid" state as soon as any Challenge for that Authz has been attempted and failed. This erratum would make that behavior unacceptable.
2) The motivation for the change is incorrect. Filing a new Order to try again does not require deactivating all of the Authorizations associated with the previous order. In fact, doing so may be detrimental, if any of those Authorizations were already "valid" and the ACME server is willing to re-use existing Authorizations with a new Order. 3) The practical benefits in the current ACME client ecosystem are virtually nonexistent. The number of ACME clients installations which are capable of fulfilling more than one challenge type (i.e. have access to DNS, the webserver's filesystem, and the webserver's handshake protocol) is vanishingly small. Most are configured with enough permissions to fulfill exactly one kind of challenge. Being able to fall back between challenge types in an attempt to fulfill an authorization will not help most clients. Aaron On Wed, Jan 3, 2024 at 8:02 AM Ilari Liusvaara <[email protected]> wrote: > On Wed, Jan 03, 2024 at 11:13:01PM +0900, Seo Suchan wrote: > > While looks sensible I wonder if how many clients pulling on auth > > instead of challanges: Those client will pull without limit if this > > behavior applied to CA > > > > For example this client do watch auths status instead of challenge > > itself. > > > https://github.com/diafygi/acme-tiny/blob/c29c0f36cedbca2a7117169c6a9e1f166c501899/acme_tiny.py#L151 > > I would imagine most clients do that. The one that I have written > certainly does (I think it would timeout with "authorization status > stuck" error after 10min). > > AFAIK, ACME does not even guarantee that challenges are fetchable. > > > And one does not have to deactivate authorizations in order to retry. > Just creating new order will either restart from scratch or resume > where one left off, depending on the CA. > > Yes, one would need autotimeouting blacklist for clients that can > try multiple methods, but I do not think that is hard (at least > compared to stuff like handling the three different concurrent > order race conditions). > > > The only reasons I know to deactivate authorizations: > - Getting rid of zombie auths that fail CAA validationmethods. > - Dropping authority to reduce damage on key compromise (explicit > clear-all would be better for this purpose). > > > > > -Ilari > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
