Hello Aaron The proposed changes will address my blocking DISCUSS once published.
About the “00” and my COMMENT about section 4.2 being unclear, up to you, but repeating the explanations you just sent me in the text will be a plus for the reader/implementer. Regards -éric PS: special thanks for using “Hi Éric” on a non-French keyboard ;-) From: Aaron Gable <aa...@letsencrypt.org> Date: Wednesday, 26 February 2025 at 22:50 To: Eric Vyncke (evyncke) <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, draft-ietf-acme-...@ietf.org <draft-ietf-acme-...@ietf.org>, acme-cha...@ietf.org <acme-cha...@ietf.org>, acme@ietf.org <acme@ietf.org>, ynir.i...@gmail.com <ynir.i...@gmail.com>, g...@apnic.net <g...@apnic.net> Subject: Re: Éric Vyncke's Discuss on draft-ietf-acme-ari-07: (with DISCUSS and COMMENT) Hi Éric, Thank you for the comments and discussion! I have updated the working copy<https://github.com/aarongable/draft-acme-ari/pull/96> with a number of these changes, and will publish a new version of the draft soon. My comments and responses are inline below. On Thu, Jan 2, 2025 at 5:49 AM Éric Vyncke via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-acme-ari-07: Discuss ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ### Section 4.1 I think that the example is wrong for HTTP request, rather than ``` GET https://example.com/acme/renewal-info/ aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE ``` it should probably be " GET /acme/renewal-info/ aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE Host: example.com<http://example.com> " Thank you, I have fixed this example. Also in this section, should the note about prefixing a "00" when the serial number is a negative number be more than a simple note but normative ? Or if this is per default in ACME, adding a reference ? This is in reference to an encoding requirement inherent to the Distinguished Encoding Rules (DER), which themselves are mandated by X.509 and RFC 5280. Due to the two's-complement encoding of ASN.1 Integers in DER, if the leading zero byte were omitted, an encode-decode cycle would transform the intended integer serial number into an unintended negative integer. It is not a requirement introduced by this document, nor even by ACME. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Lack of HTTP-dir reviews I can only regret that there was no HTTP directorate review for this document as one of my DISCUSS and one of my COMMENT are related to HTTP. ### url should be in uppercase I have detected some "url" that should be "URL" as it is an acronym. Good catch, I have fixed the two instances of this in Section 4.1. ### Section 4.2 Is the first `Conforming clients SHOULD provide this URL to their operator` correct ? I would assume that this JSON reply is sent by the ACME server and not by the client. You're correct that this JSON reply is sent by the ACME server. But some ACME clients have logging or other notification capabilities which they can use to inform their operator of exceptional circumstances. This sentence is saying that, because the explanationURL is intended to lead to human-readable documentation, the client should surface the URL to its operator so that a human can actually read the documentation if they want to. Is the `Retry-After` the most suitable HTTP header ? I.e., while RFC 9110 section 10.2.3 is not really specific, [Mozilla spec](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) seems to indicate that it is not appropriate for a 200 response code. As I am not an HTTP expert, I am ready to be corrected of course but I would think that using a new key in the returned object would be neater. I've gone back and forth on this myself. We chose Retry-After because many HTTP clients already have built-in support for respecting this header, and it does fundamentally carry the correct semantics. From the server's perspective, the client should not come back until after that time period has passed (to prevent overload). From the client's perspective, it is incentivized to come back as soon as possible after the period has passed (to get up-to-date info). If others with more knowledge and strong opinions about HTTP tell me that this is an absolutely horrible idea, I'm willing to change it, but as of right now I still think it makes the most sense. ## NITS (non-blocking / cosmetic) ### Appendix A It seems that the year of this certificate is 0000, was it the intent ? The validity interval of the example certificate is not relevant to the purpose for which it is used in this document, so I chose to make it an obviously-unusable value. I'm happy to change this if you like. ### Section 4.2 Suggest to use a more recent date (rather than 2021) in the example. Good call, done. Thanks again, Aaron
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
