My preference here would be for approach (1). I appreciate that it's a big change to make this late in the process, but that's the price we pay for missing a pretty significant issue up until now. For existing implementations, the code impact should be modest, as long as they have been architected to isolate fetch logic (i.e., the have a get() method that you could just change to do the right POST thing). And as long as we don't *forbid* responding to GET requests, servers can support both options for the time being.
To illustrate what change we'd need to make, I went ahead and wrote up a PR: https://github.com/ietf-wg-acme/acme/pull/445 On Thu, Aug 30, 2018 at 11:33 AM Adam Roach <a...@nostrum.com> wrote: > On 8/30/18 8:48 AM, Felix Fontein wrote: > > Hello, > > > On 8/30/18 7:55 AM, Richard Barnes wrote: > > Focusing on DISCUSS comment for now, will pick up COMMENTs later. > > On your DISCUSS, I think you're off on a couple of small things > > > > Yeah, I woke up with the sudden realization that I'd had the wrong > model in my head when I talked through the cert endpoint. All that's > there is a signed public cert rather than a public/private pair, so > it's not sensitive. > > > what happens if the cert URL is > nothttps://example.com/acme/cert/somerandomlookingidentifier, > buthttps://example.com/acme/acct/2/order/1/cert? Then someone can still do > identification correlation when the certificate can be downloaded > without authentication. > > > That's a good point as well. > > After some further discussion, I think there are two potential paths > forward: > > 1. Remove all uses of GET from the specification (except for > retrieving the directory), which causes all requests to be authenticated, > or > 2. Scrub all of the ACME documents to ensure that the resources that > can be retrieved without authentication cannot be correlated with each > other. > > Approach 1 (which is a stronger form of what Richard proposed in his PR) > has the advantage of closing all privacy holes, even the ones that we can't > identify at the moment. It has the disadvantage of differing from current > deployed implementations. > > Approach 2 has the advantage of being consistent with today's deployments, > but has the drawback that it it requires significant new work to identify > and address means of correlating resources with each other. It's worth > noting that the extensibility of the protocol makes it necessary to perform > this analysis every time a new field is added to a structure and every time > a new HTTP endpoint type is defined, which makes this approach extremely > fragile. In particular, the fact that individual implementations can > include arbitrary JSON fields for debugging and/or proprietary behavior > means that we're going to require implementations to independently perform > this analysis for every nonstandard field they add to the structure as well. > > /a > _______________________________________________ > 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
