STAR only requires that the server be able to GET the certificate URL, right? If that's the case, I don't see a problem, given that the latest version of the PR allows GET to certificate resources.
I don't think we can make authentication optional. That would revert us back to having to do privacy analysis for everything. Note, however, that the *authorization* that the server applies is still up to the server. If the server wants to have some external interface by which you could authorize additional people to see your stuff, they are not forbidden from doing so. --Richard On Fri, Aug 31, 2018 at 2:28 PM Fossati, Thomas (Nokia - GB/Cambridge) < thomas.foss...@nokia.com> wrote: > +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 >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
