Subject: [Acme] acme-06: Yet more editorial issues plus one real protocol thing

From: Marcos Sanz <[email-masked]>
Date: Fri, 2 Jun 2017 12:35:47 +0200

Dear all,

please allow a couple of comments from a person who reads the draft for 
the first time:

1) Structural comment: It is a bit confusing that something like, for 
instance, chapter "7.3.4 Account Deactivation" is logically ordered under 
"7.3 Account Creation".
Suggestion: Chapter 7.3 should be renamed from "Account Creation" to 
"Account Administration" and then there should be a new "7.3.1 Account 
Creation".

2) The challenge object in the example of section 7.1.4 is of type http. 
It is missing the mandatory fields "url" and "token".

3) Section 7.5.1 says

"For example, if the client were to respond to the "http-01" challenge in 
the above authorization, it would send the following request:
   POST /acme/authz/asdf/0"

However the URI of the refered authorization was /acme/authz/1234/0. As a 
matter of fact, it looks to me like all six "authz/asdf" occurrences in 
the draft should be "authz/1234" instead...

4) The example in section 8.2

GET .well-known/acme-challenge/evaGxfADs6pSRb2LAv9IZf17
Host: example.com

should be directed to the Host "example.org" which is the domain to be 
validated, not to "example.com" which is the acme server. And then the 
body of the response

HTTP/1.1 200 OK
LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI

looks strange to me. It should match the key authorization, which should 
start with the token "evaGxfADs6pSRb2LAv9IZf17", and not "Loq..."

5) The text in section 8.4

"For example, if the domain name being validated is "example.com", then 
the client would provision the following DNS record:
acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM"

would better use "example.org" for the same reasons explained above.

6) To make acme a real "REST application" and not just a REST-buzzword 
freerider, the PUT method should be used consistently for the update of 
existing resources. For instance, where in 7.5.1 the client "updates back 
to the server" the details of an existing resource (the challenge) via

POST /acme/authz/asdf/0 HTTP/1.1

, it should use instead 

PUT /acme/authz/asdf/0 HTTP/1.1

Has the latter been discussed before by the working group? Sorry if so, 
then I'd be thankful for a pointer.

Best,
Marcos