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

From: Marcos Sanz <[email-masked]>
Date: Wed, 21 Jun 2017 13:54:50 +0200

I've created PRs for all editorial comments and opened Issue 325 for the 
HTTP method usage:
https://github.com/ietf-wg-acme/acme/issues/325

Again, I'd be thankful for a pointer if this topic was already dealt with.

Best,
Marcos

----- Weitergeleitet von Marcos Sanz/Denic am 21/06/2017 13:51 -----

Marcos Sanz/Denic wrote on 02/06/2017 12:35:46:

> Von: Marcos Sanz/Denic
> An: [email-masked]
> Datum: 02/06/2017 12:35
> Betreff: acme-06: Yet more editorial issues plus one real protocol thing
> 
> 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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 21 Jun 2017 12:36:32 -0400

Thanks for the PRs.  I merged them.

I don't think that PUT is appropriate for really any requests that ACME
uses.  Quoth RFC 7231:

"""
   The PUT method requests that the state of the target resource be
   created or replaced with the state defined by the representation
   enclosed in the request message payload.
"""

None of the requests that ACME uses fully replace the state of the resource
in question.  In all cases, the client provides some additional
information, which the server incorporates into the resource.

--Richard

On Wed, Jun 21, 2017 at 7:54 AM, Marcos Sanz <[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>