I went ahead and posted a PR adding the "meta" field: https://github.com/ietf-wg-acme/acme/pull/462
On Sun, Oct 7, 2018 at 5:04 AM Thomas Fossati <[email protected]> wrote: > The 10/06/2018 17:27, Richard Barnes wrote: > > I'm not hard set against this change, I just don't see much benefit. > > > > Allowing GETs for certificate URLs is so low-risk that we weren't going > to > > access-control it at all until a couple weeks ago. Now it's so high-risk > > that we need to REQUIRE authentication? That's "REQUIRED" in the RFC > 2119 > > sense, since higher up in the section, it says that servers MUST return > 405 > > if they get a GET, except as allowed in that section. > > > > There are reasonable use cases for GETs. STAR is one, but you could > > imagine non-auto-renewed cases as well. There's no security reason to > cut > > off those GETs, so I don't understand what value we're conserving here. > > The PR says that having GETs complicates the security analysis, but this > is > > not some inner part of the protocol, it's the output. > > From the point of view of STAR this is not a big deal. We have > acme-star where to define both the plain-GET exception - which is a core > requirement for the delegation workflow - and how the server advertises > support for it. > > My worry is that by accepting this change, other legit plain-GET use > cases are automatically made either more complicated or potentially > insecure (someone might decide that sharing the account key across a > bunch of edge caches or some other HA configuration is a worth > trade-off.) > > That said... > > > The only argument that seems at all cogent here is that we don't have > > any up-front signaling for whether a server supports GET or not, just > > the error code. So clients have to guess. Maybe that's enough to > > motivate removing it for now; a later doc could come along and say > > "allow GETs and signal it with this field in the meta object". > > ... it should be pretty easy to add the needed meta object extension > directly into the acme-acme document if this is the only missing piece? > > > But if we do that, we should be clear that we're removing GET to keep > > the protocol flow clean, not for any security reason. > > Emphatic +1 >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
