I realize this topic doesn't really matter while unauthenticated GETs are still supported for the various ACME objects. But when it eventually gets turned off, I'm curious what the intent is. For things like Orders, Authorizations, and Challenges that are tied to a specific account, should any ACME…

It was my understanding that only the ACME account to which the resources (orders, authzs, challenges) belong can access them. When you say that any other account can access them as well via POST-as-GET, did you test that with Boulder? Or Pebble? Or both? I would say that it would be a bug if that’s…

I haven’t tested against Pebble or Prod Boulder yet. But it definitely works against Staging Boulder. I’ve also only tested getting authorization objects so far.

The merge of “POST-as-GET” into the spec cites “privacy concerns raised in Adam’s and Ben’s AD reviews” (but without link to theses, sadyl) : https://github.com/ietf-wg-acme/acme/pull/445 Maybe @jsha remembers? (Richard Barnes doesn’t seams of have an account here) I personally feel it’s a but tha…

@tdelmas At a guess, probably these: “Adam”: https://mailarchive.ietf.org/arch/msg/acme/cGQzjW7WQQ5oS2nrnXCXZM-2Jn8 “Ben”: https://mailarchive.ietf.org/arch/msg/acme/YLYlBVdnv2VxllVCS8pF-QueLe8

Thank you @mnordhoff ! [image] mnordhoff: “Adam”: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT) The most wiring example there ends with the email and phone number. In the Let's Encrypt context, as email validation is not allowed and the account entry poin…

[image] tdelmas: I don’t see anything much relevant there, did I missed it? Skimming the message, I didn't see a lot, but it was mentioned: Section 6.2 notes that servers MUST NOT respond to GET requests for sensitvie resources. Why are account resources the only sensitive ones? Are auth…

Thanks for finding those links, @mnorhoff! That is accurate. The specific issue raised by reviewers was that some CAs might consider the account ID-to-hostname matching sensitive. More broadly, the issue was that we had a protocol in which some elements were authenticated, and some were not, based o…

Is there any update on the deprecation schedule for unauthenticated GETs on staging? The latest update to ACME v2 - Scheduled deprecation of unauthenticated resource GETs says that POST-as-GET would be required on staging from November 1, 2019. Unauthenticated GETs seem to work today. With the priv…

[image] jsha: Right now we don’t specify any access control rules for Orders, Authorizations, and Challenges (because we don’t consider those resources sensitive) I think I may be misunderstanding what you have written here. I tried testing access across accounts and it seems like access cont…

I’m pretty sure you’re right @_az . There was a bug in the code in my initial tests that was still using the correct account instead of the alternate account. After fixing it, I’m now getting the same errors as your tests. So yay for privacy, but boo for third party troubleshooting?

POST-as-GET and privacy

Client dev

cpu November 26, 2019, 6:37pm 15

We're going to plan to roll this out in staging Dec 4th. See my latest comment on the announcement thread.

Topic		Replies	Views
ACME v2 - Scheduled deprecation of unauthenticated resource GETs API Announcements	4	30960	September 24, 2020
Any update on GETS -> POSTs conversation Client dev	10	2610	November 15, 2018
ACMEv2 - POST-as-GET on /acme/cert/? Client dev	3	1752	June 5, 2019
ACME breaking change: Most GETs become POSTs API Announcements	0	4570	August 30, 2018
Why I cannot see my account (Method not allowed)? Server	6	3950	December 31, 2016

POST-as-GET and privacy

Related topics