Hi! Thanks for the revised -08 document, and the WGLC to confirm the edits. I reviewed the IESG ballot COMMENT and the following edits are still needed.
(1) Francesca's ballot ==[ snip ]== Additionally, I would suggest to add a Description column to the IANA ACME Authority Token Challenge Type Registry, containing some short description of what the types defined are. ==[ snip]== The text introduced into Section 7.3 of -08 has typos: OLD ... and a Description of "JSON Web Token (JTW) challenge type. NEW ... and a Description of "JSON Web Token (JWT) challenge type." (2) Lars's ballot ==[ snip ]== In Section 7.1, you might want to include a specific "Note to the RFC Editor" instructing them on how to handle "[RFCThis]". ==[ snip ]== Please add such text. (3) Murray's ballot ==[ snip ]== I suggest that Section 7.1 should explicitly reference "the ACME Validation Methods sub-registry of the Automated Certificate Management Environment (ACME) Protocol registry group" or something like that. Also, I concur with Francesca's suggestion regarding this section. ==[ snip ]== Please explicitly name the registry in which the action described in Section 7.1 will be performed. OLD ... and a Description of "JSON Web Token (JTW) challenge type. NEW ... and a Description of "JSON Web Token (JWT) challenge type." (4) Eric's ballot ==[ snip ]= -- Section 8 -- The first § explicitly request TLS (what about QUIC BTW) and the last § is less specific as it only requests "MUST use confidentiality". Is there any reason for this slight difference ? ==[ snip ]== There appears to be confusion here between the communication channel between the Token Authority/ACME server (must be TLS) and entities/Token Authority (must provide confidentiality). To prevent confusion for future readers, I recommend a reminder: OLD Any protocol used to retrieve Authority Tokens from a Token Authority MUST use confidentiality to prevent eavesdroppers from acquiring an Authority Token. NEW Any protocol used to retrieve Authority Tokens from a Token Authority MUST use confidentiality to prevent eavesdroppers from acquiring an Authority Token. The details of this protocol are out of scope of this document. (5) Rob's ballot ==[ snip ]== MUST support an HTTPS REST interface Is REST well defined enough to be an RFC 2119 MUST? Does this need a reference to what constitutes a REST interface that would be compliant with this specification? ==[ snip ]== I'm checking in with the ART ADs for a recommended reference. Regards, Roman _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
