Would it work to keep certificate fetches as plain GET? In shared hosting environments it’s common for a privileged process to request certificates on behalf of user accounts. This avoids having 1,000s of ACME server registrations from a single server. While certificates are generally made available within seconds, theoretically the delay between request and issuance could be much longer (e.g., for OV/EV), such that it might be prudent for that privileged process to give the order ID to the user and have the user poll for the certificate, e.g., via cron.
-Felipe Gasper Mississauga, Ontario > On Aug 30, 2018, at 11:51 AM, Salz, Rich <[email protected]> > wrote: > > It appears that we missed a security issue. > > Please take a look at the PR mentioned below. It removes many GET requests > and turns them into POST so that the client payload can have authentication > information. > > If you object to this change, please post a note to the list and explain why. > Try to do that within a week. > > Thanks. > > From: Richard Barnes <[email protected]> > Date: Thursday, August 30, 2018 at 11:42 AM > To: Adam Roach <[email protected]> > Cc: "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with > DISCUSS and COMMENT) > > My preference here would be for approach (1). I appreciate that it's a big > change to make this late in the process, but that's the price we pay for > missing a pretty significant issue up until now. For existing > implementations, the code impact should be modest, as long as they have been > architected to isolate fetch logic (i.e., the have a get() method that you > could just change to do the right POST thing). And as long as we don't > *forbid* responding to GET requests, servers can support both options for the > time being. > > To illustrate what change we'd need to make, I went ahead and wrote up a PR: > > https://github.com/ietf-wg-acme/acme/pull/445 > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
