On 8/30/18 6:20 PM, 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.
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.
To be clear -- and I'm just repeating an observation that Richard made
-- servers can continue to accept GET for the resources in question
(order lists, orders, and certificates) for the foreseeable future,
while also accepting POST for them [1]. Doing so would allow clients to
switch from using GET to using POST for these resources at a leisurely
pace, and then servers could turn off GET functionality (i.e., start
returning 405's) once usage drops to an acceptable level.
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.
I think this is the right call also, regardless of how breaking a change
it might be. What I'd really like to avoid is a perpetual tax on
developing ACME extensions in the form of having to perform extensive
privacy analysis on every new endpoint, every new field, and every new
identifier type that can be retrieved without authentication; and, as
far as I can tell, that's the only other option here.
For avoidance of doubt, I'm speaking as an individual in the preceding
paragraph. As an AD with a DISCUSS on this document, I want to make it
clear that any solution to the privacy issue will satisfy my DISCUSS.
But as an individual, I would be sad if the decision taken was one that
hamstrings future protocol development.
/a
____
[1] This would presumably be coupled with an implementation-specific
analysis of whether GET-able information can be correlated, and making
adjustments if so.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
