Change:
client and the ACME server is the HTTPS server.  The ACME server acts as an HTTP and HTTPS client when validating challenges via HTTP. <ins> ACME servers SHOULD follow the recommendations of RFC7525 when configuring their TLS implementations.  ACME servers that support TLS 1.3 MAY allow clients to send early data (0xRTT).  This is safe because the ACME protocol itself includes anti-replay protections. </ins> ACME clients SHOULD send a User-Agent header in accordance with RFC7231, including the name and version of the ACME software in addition to the name and version of the underlying HTTP client

Discussion:
Comments / responses in this thread: URL Hello, Thank you to the editors and WG for your efforts on draft-ietf-acme-acme, it's a well written and easy to understand draft. I do have a few comments, that need to be address by the editors and SHEPHERD. Please review the idnits. There are a few warnings that should be correctable and can be addressed, but more importantly, it calls out several downrefs that are not in the shepherd writeup. These need to be in the writeup and then also mentioned in the IETF last call announcement (I'll make sure the latter happens). Here's my mostly editorial comments: Introduction: It reads very well, but it would be helpful to those unfamiliar with the work to explicitly state that ACME is about DV certificates. The first sentence of the last paragraph seems like the best place to add this in. Current text: This document describes an extensible framework for automating the issuance and domain validation procedure, thereby allowing servers and infrastructural software to obtain certificates without user interaction. Proposed: This document describes an extensible framework for automating the issuance and domain validation procedure for DV certificates, thereby allowing servers and infrastructural software to obtain certificates without user interaction. I do like how the introduction is framed as it’s clear the level of security provided by the certificates issued via ACME. Thanks for that. The introduction should also make it clear that ACME can be used for other services using DV certificates, not just HTTP. This is mentioned in the Terminology section, but I think a clear sentence upfront would be helpful. Section 2: Nit/suggestion: Change the tense to read as a published RFC in the last paragraph, last sentence (take it or leave it). Current: Such close integration of ACME with HTTPS servers would allow the immediate and automated deployment of certificates as they are issued, sparing the human administrator from much of the time-consuming work described in the previous section. Proposed: Such close integration of ACME with HTTPS servers allows the immediate and automated deployment of certificates as they are issued, sparing the human administrator from much of the time-consuming work described in the previous section. IANA Section: Everything looks good except that RFC5226 has been obsoleted, so the new reference is RFC8126 and “specification required” URL still means the same thing, so using that is fine.

Security considerations: I think it would be good to mention here that they are DV certs so the reader understands from he introduction and this section the level of cert issued through ACME and doesn’t assume a higher level of assurance. s/ACME is a protocol for managing certificates/ACME is a protocol for managing DV certificates/ I know this is obvious to the people in the WG, but a reference to RFC7525 to properly configure TLS 1.2 should be included to protect against the mentioned attacks. If you want to also reference TLS 1.3 and specify no 0-RTT that would be good too. It’d be great to see this get widely deployed, so there may be a number of newcomers reading this to make their lives easier with cert issuance/maintenance. what if the server that the account verifier has an account on (client for ACME) is compromised and is used to request new certificates or perform other actions? I think this is one of the larger risks, so mentioning this is possible and hardening measures should be taken to prevent compromise would be prudent. Hardening measures or appropriate security controls should be broadly understood terms (I think) so that you wouldn’t need to list out things like turing off unnecessary services. I would think you’d see requests for new phishing domains rather than known ones through this process. What would you look for there as that’s a complex problem - it would be hard to know all legit names to know if one was a play off of the original. This happened with equifax - they provided a site name with a typo and a ‘white hat’ attacker had set up a site that looked just like theirs at that site. But it was announced by equifax. Tough problem as automating a check on the DNS registration may not detect something unusual, but maybe recommending this check could help? RDP lessens what needs to be shared from whois though, although I don’t think that’s widely deployed. Best regards, Kathleen