> How does using POST address this?

Please read the draft. We're talking about POSTs authenticated with JWS not
vanilla HTTP POSTs.

On Fri, Aug 31, 2018 at 3:34 PM, Nico Williams <n...@cryptonector.com>
wrote:

> On Thu, Aug 30, 2018 at 04:20:41PM -0700, Jacob Hoffman-Andrews wrote:
> > ACME currently has unauthenticated GETs for some resources. This was
> > originally discussed in January 2015[1]. We decided to put all sensitive
> > data in the account resource and consider all GET resources public, with
> a
> > slant towards transparency.
> >
> > Adam Roach recently pointed out in his Area Director review that even
> when
> > the contents of GET URLs aren’t sensitive, their correlation may be. For
> > instance, some CAs might consider the grouping of certificates by
> account to
> > be sensitive.
>
> This is true, but GET isn't the issue.  If you have iterable URI
> constructions then POST will let you iterate them just as well as GET.
>
> > Richard Barnes proposes[2] to change all GETs to POSTs (except directory
> and
> > new-nonce). This will be a breaking change. Clients that were compatible
> > with previous drafts, informally called ACMEv1 and ACMEv2, will not be
> > compatible with a draft that mandates POSTs everywhere. It will be a
> painful
> > change, since the ecosystem just started switching to ACMEv2, which
> looked
> > to be near-final.
>
> How does using POST address this?
>
> Neither does GET imply unauthenticated, nor does POST imply
> authenticated.
>
> GET vs POST can make a difference in the context of HTML (where you can
> get a user-agent to GET a resource without the user taking action), but
> I don't think that's relevant here.
>
> > I think this is the right path forwards. ACME will be a simpler, better
> > protocol long-term if all requests are authenticated. However, if we’re
> > taking this path we should aim to come to consensus and land the final
> spec
> > quickly to reduce uncertainty for ACME client implementers.
>
> This is wrong.  GET vs POST makes no difference as to iteration of
> resources.
>
> Please use HTTP correctly.
>
> If a resource is read-only or GETs of it would be idempotent anyways,
> then use GET.
>
> Do include normative text about the shape of the URIs to prevent
> iteration via monotonic increment of numeric components or query
> parameters.
>
> Do specify what requires authentication and what does not.
>
> Do not misuse HTTP verbs.
>
> Nico
> --
>
> _______________________________________________
> 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

Reply via email to