> The narrow fix -- Remove "orders." No one implements it, and this is the
> least disruptive option to a mature spec.
I support this narrow fix.
On Mon, Oct 8, 2018 at 3:25 PM Jacob Hoffman-Andrews wrote:
> The POST-as-GET mess started because Adam Roach pointed out that the
> "orders" URL
The POST-as-GET mess started because Adam Roach pointed out that the
"orders" URL (listing all of an accounts orders), in some non-WebPKI
contexts, could expose information that shouldn't be exposed.
There are two possible fixes for this:
The narrow fix -- Remove "orders." No one implements
The 10/08/2018 09:49, Yaron Sheffer wrote:
> 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
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.
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
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
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
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
Speaking as Area Director: there is no process problem with this reference.
Of course, it's a WG decision whether it's advisable.
-Ekr
On Sat, Oct 6, 2018 at 8:31 AM Salz, Rich wrote:
> In order to address an issue raised during IESG review, unauthenticated
> GET for ACME server resources was
