Hi Ben,
Thanks for the comments. A couple of replies are below; resulting edits
are in this PR:
https://github.com/ietf-wg-acme/acme/pull/441
--Richard
On Tue, Aug 28, 2018 at 10:46 PM Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-acme-acme-14: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
>
>
>
> --
> COMMENT:
> --
>
> Thanks for the work on this; I'm happy to see it nearing completion. I
> have a
> few minor comments:
>
> *** Substantive ***
>
> §6.1: "The ACME server acts
>as an HTTP and HTTPS client when validating challenges via HTTP."
>
> Section 8.3 says that HTTP challenge validation cannot use HTTPS. Also, §6
> says
> that all interactions between the client and server use HTTPS. I recognize
> challenge validation is not really an interaction between the client and
> server, but I suspect some readers may be confused.
>
Done.
> - "ACME servers SHOULD follow the recommendations of [RFC7525] when
>configuring their TLS implementations."
> Why not MUST?
>
I believe the WG discussed this and decided that there was not a need to be
overly prescriptive here.
> §7.3: "... and the server MUST reject new-account
>requests that do not have the "termsOfServiceAgreed" field set to
>"true". "
>
> The MUST seems overly strong there; is there no room for local policy?
> Would it
> be completely insane to offer optional ToS? (For example, maybe one gets
> some
> additional service for agreeing to terms, but still gets a cert either
> way.)
>
Edited to "If the server wishes to require the client to agree to
terms...".
> - "Clients SHOULD NOT automatically agree to terms by default."
> Why not MUST NOT?
>
Same as the SHOULD NOT for warning the user below -- this is a UX / legal
issue.
> §8.3:
>
> - Is there a lifetime after which a provisioned HTTP resource in response
> to a
> challenge should go away?
>
Good question. There has been discussion of "continuous validation", where
the CA would re-do validation over the life of a certificate, but I don't
think that's ever done in practice right now. And if someone wants to do
that, they can define a new challenge "http-continuous-01".
I've noted that you can remove the resource once validation is complete.
And the same for the DNS challenge, actually.
> *** Editorial and Nits ***
>
> §2, first paragraph: Is the "user" the person requesting services from the
> ACME
> server?
>
Yes, but it's easier just to replace "the user's" with "a" :)
> §10.2: "
>It is RECOMMENDED that the server perform DNS queries and make HTTP
>connections from various network perspectives..."
>
> §7.3.6: " The inner JWS is NOT REQUIRED to have a "nonce" header
> parameter."
>
> "NOT REQUIRED" is not among the terms defined by 2119/8174. I suspect this
> is
> intended as a statement of fact, and should therefore not be capitalized.
>
Changed "NOT REQUIRED to have" to "MAY omit". I do want some 2119/8174
language here since it's modifying normative requirements above
> I'm not sure what that means. Given that this uses an upper-case
> RECOMMENDED,
> can it be stated more concretely?
>
Not totally sure what's unclear here, but I added some words to try to
clarify.
> §13.3: Is this section also to be removed?
>
Yes, but presumably that will take care of itself once the reference is
removed in the XML. In any case, this section is auto-created, so I can't
really edit it.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
