[Acme] Re: Éric Vyncke's Discuss on draft-ietf-acme-ari-07: (with DISCUSS and COMMENT)

[Aaron Gable <[e-mail]>]

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 <[e-mail]>
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
> "
>

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