Change:
Thanks for the comments NAME I've updated the PR to address.
There has been list discussion on this PR and consensus is positive. I'm going to merge this now that NAME has addressed the feedback provided.
LGTM :rocket:

Discussion:
because the ACME protocol itself includes anti-replay protections (see replay-protection). <del> 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 software. </del> <ins> ACME clients MUST send a User-Agent header, in accordance with RFC7231.  This header SHOULD include the name and version of the ACME software in addition to the name and version of the underlying HTTP client software. </ins> ACME clients SHOULD send an Accept-Language header in accordance with RFC7231 to enable localization of error messages.

11.1. <ins> ACME relies on two different classes of key pair: Account key pairs, which are used to authenticate account holders Certificate key pairs, which are used to sign and verify CSRs (and whose public keys are included in certificates) Compromise of the private key of an account key pair has more serious consequences than compromise of a private key corresponding to a certificate.  While the compromise of a certificate key pair allows the attacker to impersonate the entities named in the certificate for the lifetime of the certificate, the compromise of an account key pair allows the attacker to take full control of the victim's ACME account, and take any action that the legitimate account holder could take within the scope of ACME: Issuing certificates using existing authorizations Revoking existing certificates Accessing and changing account information (e.g., contacts) Changing the account key pair for the account, locking out the legitimate account holder For this reason, it is RECOMMENDED that account key pairs be used for no other purpose besides ACME authentication.  For example, the public key of an account key pair SHOULD NOT be included in a certificate.  ACME clients and servers SHOULD verify that a CSR submitted in a finalize request does not contain a public key for any known account key pair.  In particular, when a server receives a finalize request, it MUST verify that the public key in a CSR is not the same as the public key of the account key pair used to authenticate that request. 11.2. </ins> As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control and thus mis-issuing certificates.  Servers SHOULD perform DNS

these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.). <del> 11.2. </del> <ins> 11.3. </ins> The http-01, and dns-01 validation methods mandate the usage of a random token value to uniquely identify the challenge.  The value of

that automatically replies to challenges without participating in the creation of the initial authorization request. <del> 11.3. </del> <ins> 11.4. </ins> ACME provides certificate chains in the widely-used format known colloquially as PEM (though it may diverge from the actual Privacy