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 <b...@nostrum.com> 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