On Wed, Sep 1, 2021 at 8:28 PM Michael Richardson <[email protected]> wrote:
> > Ryan Sleevi <[email protected]> wrote: > >> This seems to make the ACME server keep a bunch of state itself > (across > >> multiple HTTPS/TLS connections), while I suspect that most of us > would like > >> the client to be responsible for keeping that authorization around. > >> > >> Would you agree with this? > > > > I'm not sure I understand this. Isn't it already the case today that > ACME > > servers necessarily need to track this state? > > 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. As Aaron mentioned, I'm not only not aware of implementations that do what you describe, but I also don't believe this was a design goal/constraint of ACME to support. Indeed, it explicitly runs counter to the use cases that were intended to be supported with the design (e.g. external accounts or additional vetting). Are you aware of implementations - clients or servers - that behave as you describe? It would be interesting to learn more about them, and what sort of use cases they exist to support, since it doesn't seem to fit with the primary use cases ACME was designed to address.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
