Responses to COMMENT comments inline below (DISCUSS part trimmed). PR here:
https://github.com/ietf-wg-acme/acme/pull/448 On Thu, Aug 30, 2018 at 12:50 AM Adam Roach <a...@nostrum.com> wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have a small handful of substantive comments, and several editorial nits. > > --------------------------------------------------------------------------- > > General: > > This protocol specifies the use of RFC 3339 time formats in several > places. Most > modern protocols that reference RFC 3339 choose to place further > restrictions on > the format; commonly, the time-secfrac portion is required to be omitted, > and > the time-offset portion is required to be "Z". In addition to making > parsing > easier, these restrictions have the property of any given time having only > one > possible string representation. > > My suggestion would be for ACME to include similar restrictions. > Alternately, if > the full range of optionality allowed by RFC 3339 is actually intended, > please > adjust the examples so that at least a few of them include fractional > seconds > and non-UTC timezones. > Unless you can point me to an easy-to-specify, univserally-supported-for-generation-and-consumption spec, I'm just going to leave this as it is. > --------------------------------------------------------------------------- > > §5: > > For avoidance of doubt, this section should probably indicate that values > that > will appear in certificates will be used and conveyed in the form present > in > certificates, possibly with a reference to RFC 5280 section 7. > Done, but in the section 7.1.4 where we define the "dns" identifier type. > --------------------------------------------------------------------------- > > §6.4.1: > > > The server MUST generate the value provided in > > Replay-Nonce in such a way that they are unique to each message, with > > high probability. For instance, it is acceptable to generate Replay- > > Nonces randomly. > > It's not clear whether the values need to also be unpredictable; e.g., > would it > be okay if the value of the nonce for operation n+1 could be easily > derived or > guessed from the nonce for operation n? > Done. > --------------------------------------------------------------------------- > > §7.4.2: > > > GET /acme/cert/asdf HTTP/1.1 > > Host: example.com > > Accept: application/pkix-cert > > > > HTTP/1.1 200 OK > > Content-Type: application/pem-certificate-chain > > This pairing of "Accept: application/pkix-cert" with "Content-Type: > application/pem-certificate-chain" seems to be at odds with the > description in > RFC 7231 §5.3.2. I know that proactive negotiation is optional in HTTP, > but it > seems that it would be much better to show this as something like: > > GET /acme/cert/asdf HTTP/1.1 > Host: example.com > Accept: application/pkix-cert, application/pem-certificate-chain;q=0..5 > This was noted in Alexey's review, and is fixed in the corresponding PR: https://github.com/ietf-wg-acme/acme/pull/442 > =========================================================================== > > All of my remaining comments are editorial in nature, and most of those are > minor editorial nits. > Using my editorial discretion, I've just marked these as "Done" or "Disagree". i-d nits reports: > > ** There are 3 instances of too long lines in the document, the longest > one > being 15 characters in excess of 72. > > I'm not sure it's reasonable to expect the RFC editor to have enough > knowledge > to know how to best split the key authorization across lines (or to elide > portions of it, whichever makes more sense). > Done. > --------------------------------------------------------------------------- > > i-d nits also reports: > > -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is > not > defined in RFC 2119. If it is intended as a requirements expression, > it > should be rewritten using one of the combinations defined in RFC 2119; > otherwise it should not be all-uppercase. > This was noted in another IESG review (I think Ben's), and fixed in the corresponding PR. > --------------------------------------------------------------------------- > > §1: > > > Existing Web PKI certificate authorities tend to use a set of ad hoc > > protocols for certificate issuance and identity verification. In the > > case of DV certificates, a typical user experience is something like: > > I expect this text won't age gracefully. Even at the time of publication of > this document, over 64% of all certificates issued on the web have been > issued > using the ACME protocol, arguably making it the "typical user experience." > (see > > https://censys.io/certificates/report?q=tags%3Atrusted&field=parsed.issuer.organization.raw&max_buckets=50 > ) > > I suggest caveating this paragraph with text along the lines of "prior to > the > advent of the protocol described by this document, the typical user > experience > was..." > Disagree. > --------------------------------------------------------------------------- > > §1: > > > For example, as of this writing, there is > > ongoing work to use ACME for issuance of Web PKI certificates > > attesting to IP addresses [I-D.ietf-acme-ip] and STIR certificates > > attesting to telephone numbers [I-D.ietf-acme-telephone]. > > Suggestion: consider including [draft-ietf-acme-email-smime] in this list.. > Disagree. --------------------------------------------------------------------------- > > §6.2: > > > These intermediaries can also change values in the request that are > > not signed in the HTTPS request, e.g., the request URL and headers. > > Nit: "...header fields." > Done. > --------------------------------------------------------------------------- > > §6.4: > > > An error response with the > > "badNonce" error type MUST include a Replay-Nonce header with a fresh > > nonce. > > Nit: "...header field..." > I think all of these were addressed in the response to Alexey's review. https://github.com/ietf-wg-acme/acme/pull/442 --------------------------------------------------------------------------- > > §7.5: > > > When a client receives an order from the server it downloads the > > authorization resources by sending GET requests to the indicated > > URLs. > > Nit: "...from the server, it downloads..." > Done.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
