Re: [Acme] [Technical Errata Reported] RFC8555 (6317)

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 <ilariliusvaara@welho.com>
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
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>