Hi Geoff,
Thank you for the comments! Specific notes in-line below.
On Sat, Nov 23, 2024 at 6:16 PM Geoff Huston via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Geoff Huston
Review result: Ready with Nits
Overall the specification is quite reasonable. I have some nots that I feel
would improve the readability of the document.
1. Introduction, "All three techniques lead to load clustering for the
issuing CA."
I'm not sure I see the logic behind this assertion. I can parse this more
successfully if the text said "All three techniques may lead to load
clustering for the issuing CA due to the inability of the issuing CA to
schedule renewal requests".
I like this phrasing, and will incorporate it in the next version of the draft.
2. Introductioon: "Allowing issuing CAs to suggest a period in which clients
should renew their certificates enables for dynamic time-based load
balancing."
There is a word missing here - enables WHAT?
I believe it's actually that there's one word ("for") too many! Does this phrasing work better for you:
"Allowing issuing CAs to suggest a period in which clients
should renew their certificates enables dynamic time-based loadbalancing."
3. Introduction, "by which ACME clients may inform ACME servers that a
certificate has been renewed and replaced."
I'm confused - I thought it was up to the server to renew and replace a
certificate, not the client. This sentence suggests the opposite.
It's up to the server to issue a new certificate, but it's up to the client to both a) request the issuance of that certificate; and b) know what prior certificate this new one is replacing. ACME doesn't have a native concept of certificate "lineages", nor even a direct concept of "renewal" -- each certificate issuance request (new order) is wholly independent of all previous requests. Until ARI, that is.
I've changed the phrasing here to "by which ACME clients may inform ACME servers that they have successfully renewed and replaced a certificate." I think this phrasing will help resolve the confusion you ran into.
4. Section 4.2 RenewalInfo Objects. The structure of this section is not
obvious to the reader. I suggest selective indentqation to highlight the
structure of the paragraph. For example:
The structure of an ACME renewalInfo resource is as follows:
- suggestedWindow (object, required): A JSON object with two keys,
"start" and "end", whose values are timestamps, encoded in the format
specified in [RFC3339], which bound the window of time in which the CA
recommends renewing the certificate.
Agreed. In fact, I've been trying to get these to format the same way as in RFC 8555, with the first line of each paragraph outdented and the rest of the paragraph indented. Unfortunately I've been unable to convince xml2rfc to produce that for me. If anyone has tips on accomplishing this, I'd love to hear them.
5. Section 5 Extensions to the Order Object The same commect er per section
4.2 - some rudimentary text markup the structure of the paragraph would
help.
6. Section 6 Security Considerations.
This specification assumes time synchronisation betwEen client and server.
It would be useful for the document to note the potential failure modes when
client and server are not time-synchronised.
Interesting point! I hadn't previously considered this specification as requiring any higher degree of synchronization than the issuance process -- which has multiple objects, including certificates themselves, with expiry deadlines that work must be completed before -- already does. But you raise a very good point, and I'm adding some language addressing this now.
You can see the edits I've made in response to this email here: https://github.com/aarongable/draft-acme-ari/pull/84
Thanks again,
Aaron
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
