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 not
https://example.com/acme/cert/somerandomlookingidentifier, but
https://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
[email protected]
https://www.ietf.org/mailman/listinfo/acme
