Any update on GETS -> POSTs conversation


#1

Continuing the discussion from ACME breaking change: Most GETs become POSTs:

Just curious if there is any news on this topic?


#2

We’re going to be posting an API announcement in the next day or so.

In the meantime here’s a quick summary of my understanding of things (subject to change!):

  1. The POST-as-GET change met consensus and was merged into the draft specification yesterday. There hasn’t been a new numbered draft cut yet but I expect that will happen soon in order to enter another last-call. - https://tools.ietf.org/html/draft-ietf-acme-acme-15 captures this change.
  2. Pebble’s support for mandatory POST-as-GET was merged today and you can begin implementing client support using Pebble with the -strict flag.
  3. I filed an issue to implement optional POST-as-GET for Boulder. “Optional” meaning we’ll handle POST-as-GET requests to resources but also continue to allow unauthenticated GET requests to the same resources for some time
  4. We’ll pick a date in the future based on the state of the ecosystem to disable unauthenticated GET requests to resources for the V2 API. This will bring Boulder in line with Pebble’s -strict implementation.

None of this will affect the legacy V1 API. Earlier discussion included the idea we might implement a “V3” API for this change but I believe current consensus internally is leaning towards a flag day with the V2 API. I expect we’ll make a final decision about this in the next day or two ahead of a formal API announcement.

I hope that summary helps! Overall I’m sorry about this late breaking change. It’s challenging participating in standards work and I’m very sympathetic to the client developers that have to jump into action to address this in their clients.


#3

I think this is going to lead to a lot of broken wildcard renewals because we have a lot of Certbot users who don’t have regular client upgrades (which you can see in the server-side client statistics). I would still advocate for the v3 idea as originally suggested.


#4

These users would experience the same breakage when the V2 API was removed in favour of V3. If we schedule the V2 API flag day with this difficulty in mind I don’t think its significantly worse.


#5

We’ve posted our API announcement outlining the plan for POST-as-GET support & deprecation of unauthenticated GETs for ACME v2.

We’re targeting November 1st, 2019 for this.


#6

Thanks for the update, @cpu. So it sounds like the timeline for client devs adopting POST-as-GET (PaG) support should look something like this.

  • Today
    • Start working on a branch of your client that transitions to PaG using Pebble as the test server
  • Date X when Staging supports PaG
    • Verify branch works properly against staging.
    • (Optional) Release client that uses PaG only against staging.
  • Date Y when Production supports PaG
    • Release updated client that defaults to PaG
  • November 1, 2019
    • Relax because users who are up to date shouldn’t have any issues with the disabling of unauthenticated GETs
    • Users who haven’t upgraded to the release from Date Y or later will break.

#7

This client implementation plan sounds sensible to me. I’d estimate that “Date X” is likely to be in the next week or two, with Date Y following a week afterwards.


#8

Also just to clarify, do I have this right? The only resources that will continue to be available without PaG after November 1, 2019 are:

  • Directory
    • Forever GET’able
  • newNonce
    • Preferably HEAD, but also GET’able
  • Certificates
    • Though this is a Let’s Encrypt specific implementation decision based on the “MAY allow” phrasing in Section 6.3. Other ACME servers may choose not to allow it.

#9

Both correct :white_check_mark:

I need to verify our plans here with @jsha and @roland. I believe our intention is to only suport POST-as-GET to certificates. The MAY allow you’re referring to was recently removed in the working copy of the draft.


#10

Yep, that’s correct. We’ll treat certificates the same way we treat other resources: GETtable for now, but POST-as-GET in the future, to match the latest spec (draft-16).