Draft: draft-ietf-acme-acme

Commentary: Comments / responses in this thread :
Mailing list commentary: 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 ” 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 does n’t assume a higher level of assurance . s / ACME is a protocol for managing certificates / ACME is a protocol for managing DV certificates/ 10.1 - 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 . 10.2 - 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 would  need to list out things like turing off unnecessary services . 10.5 - 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 do n’t think that ’s widely deployed .
Paragraph (version B):
It should be noted that while the focus of this document is on
validating domain names for purposes of issuing certificates in the
Web PKI, ACME supports extensions for uses with other identifiers in
other PKI contexts.  For example, as of this writing, there is
ongoing work to use ACME for issuance of WebPKI certificates
attesting to IP addresses I-D.ietf-acme-ip and STIR certificates
attesting to telephone numbers I-D.ietf-acme-telephone.
Paragraph (version A):
In this way, it would be nearly as easy to deploy with a CA-issued
certificate as with a self-signed certificate.  Furthermore, the
maintenance of that CA-issued certificate would require minimal
manual intervention.  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.
Paragraph (version B):
In this way, it would be nearly as easy to deploy with a CA-issued
certificate as with a self-signed certificate.  Furthermore, the
maintenance of that CA-issued certificate would require minimal
manual intervention.  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.
Paragraph (version B):
ACME servers SHOULD follow the recommendations of RFC7525 when
configuring their TLS implementations.  ACME servers that support TLS
because the ACME protocol itself includes anti-replay protections.
Paragraph (version A):
All of these registries are under a heading of "Automated Certificate
Management Environment (ACME) Protocol" and are administered under a
Specification Required policy RFC5226.
Paragraph (version B):
All of these registries are under a heading of "Automated Certificate
Management Environment (ACME) Protocol" and are administered under a
Specification Required policy RFC8126.
Paragraph (version A):
There are several ways that these assumptions can be violated, both
by misconfiguration and by attacks.  For example, on a web server
that allows non-administrative users to write to .well-known, any
user can claim to own the web server's hostname by responding to an
HTTP challenge, and likewise for TLS configuration and TLS SNI.
Paragraph (version B):
There are several ways that these assumptions can be violated, both
by misconfiguration and by attacks.  For example, on a web server
that allows non-administrative users to write to .well-known, any
user can claim to own the web server's hostname by responding to an
HTTP challenge, and likewise for TLS configuration and TLS SNI.
Similarly, if a server that can be used for ACME validation is
compromised by a malicious actor, then that malicious actor can use
that access to obtain certificates via ACME.