Re: [Acme] ACME breaking change: Most GETs become POSTs

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 <jsha@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
>