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 [email protected] https://www.ietf.org/mailman/listinfo/acme
