Thanks Roman, I implemented most of these, but I'm confused by the request for a Description column for the ACME Authority Token Challenge Type registry: the -08 version of the specification included a Description column that in the registry in 7.3. Is there something else we need to add?
I think the simplest way to solve the REST specification problem (a known problem) is simply to cut the word "REST" from that sentence, i.e. "MUST support an HTTPS interface for Authority Token acquisition as described below." The description of the interface below is RESTful, sure, but it tells you what you're supposed to do with HTTP rather than just saying "use REST" or something. Jon Peterson Neustar (a TransUnion company) On 10/20/22, 8:54 PM, "Acme on behalf of Roman Danyliw" <[email protected] on behalf of [email protected]> wrote: 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!N14HnBHF!4jaa5VyOysCMmKEozjplToU1xfv-TekzxUDCo_InGC0k6_rLWzXLriaO9xoFpEGAvdoCj_eDs6BHtD7wYY3p5w$ _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
