I have updated the pull request here with a couple of major changes: * Instead of using the "typ" header parameter to signal POST-as-GET, the client signals a POST-as-GET request by sending an empty JWS payload. It seems like all of the actual-POST requests we have send a JSON object, so this should be a reliable distinguisher.
* GET requests are now allowed for certificate resources, with a recommendation for CAs to use capability URLs if they want access control. * Servers MUST return a 405 if they get a GET for a resource other than directory/newNonce/certificate. The last change makes this a harder break for current clients/servers. But it's only breaking in the sense that they're not in compliance with the RFC; you can operate a non-RFC-compliant service, no protocol police. And I think it results in a cleaner, more reliable definition here. --Richard On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews <j...@eff.org> 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. > > 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. > > [1] https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712 > [2] https://github.com/ietf-wg-acme/acme/pull/445/files > > _______________________________________________ > 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
