I'll skip those points where we agree, and just answer your queries:
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 load
balancing."
yes, I can now parse this sentence. A simpler sentence would be
'Allowing issuing CAs to suggest a period in which clients
should renew their certificates enables a form of CA load balancing."
(I don't think "dynamic time-based" actually adds enyting to the sentence!)
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<https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.2>, 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.
The <list> and "hangText attribute of the <t> element might help you here (it's
been
some years since I've had to wrangle with xml2rfrc, and those have been good
years! :-) )
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.
A visible subset of end clients have a broken concept of the current time
(see https://www.potaroo.net/ispcol/2018-11/time.html if you are interested).
This specification has
chosen to use absolute (UTC) time rather than relative time, which means that
this
lack of unversal adherence to synchronised time is a consideration here (an
alternative
could've been to use time offsets relative to the time that the response was
generated, but
I suspect that this would have its own wrinkles as well!)
Some cautionary words that say that the load balancing properties of this
measure
depends of a synchronised view of time, which is not assured.
While the draft says: "If the selected time is in the past, attempt renewal
immediately.I" it is not clear to me that if the time provided by the server
is ALWAYS in the future (because the client's local time is lagging UTC) that
the
algorithm described in the draft (the 6 steps) would allow the client to
simply perform the renewal in any case at some point.
cheers Aaron - I hope these comments help
Geoff
_______________________________________________
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org
