+1 As noted by Felipe, the implication that the service effectively consuming the certificate has to have the ACME account's key at hand is not always a practical nor a particularly secure arrangement. (Another example where this wouldn't work out particularly well is a single ACME STAR certificate shared across multiple service instances in a HA configuration.) Broadly speaking, it looks like this is going to be problematic in all cases where you'd want to decouple the certificate requester from the certificate consumer roles.
In particular, I'm very concerned about the impact on STAR Requests. In both its forms - as an ACME profile [1] as well as a standalone protocol [2] - the design postulates that the certificate resource is public. This is a core precondition to allow delegation without sharing credentials between the delegating and the delegated entities. The authenticated POST-as-GET access to the certificate resource completely wrecks this architecture. So, my question (just to be super clear: scoped only to the "POST-as-GET certificate" part of the proposed change) is: Can we let the ACME user decide whether to enable or disable this specific behaviour instead of making it mandatory for everyone? Cheers, thanks [1] https://github.com/thomas-fossati/I-D/blob/acme-delegation-profile/STAR-Request/draft-sheffer-acme-star-delegation.md [2] https://github.com/thomas-fossati/I-D/blob/acme-delegation-profile/STAR-Request/draft-sheffer-acme-star-request.md ________________________________________ From: Acme <acme-boun...@ietf.org> on behalf of Felipe Gasper <fel...@felipegasper.com> Sent: 30 August 2018 20:17 To: Salz, Rich Cc: acme@ietf.org Subject: Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT) 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 <rsalz=40akamai....@dmarc.ietf..org> > 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 <r...@ipv.sx> > Date: Thursday, August 30, 2018 at 11:42 AM > To: Adam Roach <a...@nostrum.com> > Cc: "felix=40fontein...@dmarc.ietf.org" <felix=40fontein...@dmarc.ietf.org>, > "acme@ietf.org" <acme@ietf.org> > 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 > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
