Hello, I reviewed the draft and believe it is largely ready, with a few suggestions:
1. A normative reference to RFC 7231 is needed for the Retry-After header. 2. Consider adding guidance for appropriate selection of Retry-After values. Likely this guidance will need to instruct ACME server operators to be aware of some of the policy specific elements (e.g., revocation timelines) of the PKI in which the ACME server operates. For example, a Retry-After value of 86400 would not be sufficient for the TLS webPKI, as the TLS Baseline Requirements requires revocation within 24 hours in certain circumstances; a more aggressive cadence is needed. 3. In section 4.1, replace “AKI” with “AKI keyIdentifier” in the ASCII diagram to make it clear that only the keyIdentifier field of the AKI extension is included and not the other fields of the AKI extension. The prose above says this, but consistency in both the prose and the diagram would make this clear. Thanks, Corey From: Yoav Nir <ynir.i...@gmail.com> Sent: Monday, October 7, 2024 1:57 PM To: IETF ACME <acme@ietf.org> Subject: [Acme] WGLC for draft-ietf-acme-ari Hi, all This begins a working group last call for the ARI draft [1] If you haven’t done so recently, please read the latest (-05) version of the draft, and send comments to the list. Due to the Jewish holidays and my upcoming vacation, this WGLC will last for three weeks, ending on Monday, October 28th. Please send your comments early, so that a discussion may result. Tomofumi & Yoav [1] https://datatracker.ietf.org/doc/draft-ietf-acme-ari/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
