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

[Yaron Sheffer <[e-mail]>]

Hi Richard,

I think we're in a good place, even from a STAR perspective (where 
certificates must be accessible with a GET, or the whole thing breaks 
down). To clarify the behavior further, I suggest to add the following 
text after the paragraph that says that "The server MAY allow GET 
requests for certificate resources...":

The server MAY choose to allow GET requests to certain certificate 
resources but not to others. The server can base this decision on 
out-of-band knowledge (e.g., to allow GET requests to certificates owned 
by a certain account) or on order-specific information, such as the 
extension defined in {{?I-D.ietf-acme-star}}.

Thanks,
     Yaron

On 01/09/18 01:08, Richard Barnes wrote:
> Hey all,
>
> This thread forked into a couple of different issues, so I wanted to 
> post a little end-of-day summary of the issues and where we stand.  
> I've updated the PR [1] to reflect most of today's discussion.
>
> ===
>
> ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing 
> the privacy analysis?
>
> It seems like there's pretty strong agreement that we should get rid 
> of GET, as the architecturally cleanest option.
>
> ===
>
> ISSUE 2: How should we signal that POST-as-GET request is different 
> from other POST requests?
>
> The current PR signals this by sending a JWS with an empty 
> (zero-octet) payload, instead of a JSON object.  Jacob and Daniel 
> suggested that we should instead use the payload being an empty JSON 
> object as the signal.  An earlier draft PR used a field in the 
> protected header.
>
> ===
>
> ISSUE 3: Should servers be required to allow GET requests for 
> certificate URLs?
>
> I had proposed this earlier today; Jacob and Daniel pushed back.  I 
> have implemented a compromise in the latest PR, where servers MAY 
> accept GET requests.
>
> ===
>
> ISSUE 4: How should we address the risk that an attacker can discover 
> URLs by probing for Unauthorized vs. Not Found?
>
> There seemed to be agreement on the list that this should be addressed 
> with some guidance to servers on how to assign URLs.  I have just 
> added some text to the PR for this.
>
> ===
>
> It seems to me we're pretty much closed on the first issue, and the 
> other three are still open.  Please send comments, so we can resolve 
> this issue and get the document back in motion!
>
> Thanks,
> --Richard
>
> [1] https://github.com/ietf-wg-acme/acme/pull/445
>
> On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews <[e-mail] 
> <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/acme
>