IMO Richard's proposal is too coarse, in the sense that servers may want
to publish some certificates with GET and others with POST-as-GET. So
either this should not be a server-wide flag, or if it is, it should be
augmented by a per-Order flag where the client can request what it needs.
Before this PR, the expectation is that certificates are only published
with POST-as-GET by default. But extensions (such as STAR) can mandate
that specific classes of certs be published with GET. If we don't want
explicit per-Order signaling, we'd better leave the current text as-is.
Thanks,
Yaron
On 07/10/18 22:48, Richard Barnes wrote:
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
<thomas.foss...@nokia.com <mailto:thomas.foss...@nokia.com>> 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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
