On Wed, Sep 1, 2021 at 5:28 PM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> Yes, but not necessarily across TLS connections. > > One connects, gets a challenge, sets it up (DNS or HTTP/S), waits for the > authorization check to complete, and sends an order. > > I don't know what letsencrypt does, but my understanding is that I could do > all of this on the same connection, and afterward, aside from the > certificate > that I append to a database, there is no other moving parts. I do not believe this is an accurate description of the ACME protocol, and certainly not of any implementation of it that I'm aware of (but I may be wrong!). It is true that one could imagine an ACME server which never performs authorization re-use. It would not support pre-authorization, as it always creates new authorizations for every name in each new order. Such a server would be able to support the extensions to the newOrder endpoint proposed by this draft, but would not be able to support the extensions to newAuthz proposed by this draft or proposed by my message above. That said, even such a server is required to keep state about its authorizations for arbitrarily long periods of time: the authorizations are created (including the `wildcard` boolean) when the client requests a newOrder; they are served when the client requests details about the authorizations for the order; they are updated when the client fulfills challenges; and they must be examined by the server when the client requests to finalize the order. Each of these requests is a separate HTTP/TLS connection from the client to the server, and they may be seconds, hours, or even days apart, depending on the `expires` timestamp that the server populates in the order object. Aaron
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
