Draft: draft-ietf-acme-acme

Commentary: In , I forgot to make one change that had been privately agreed among the authors and EKR . This PR just incorporates that change . 
 I ca n't merge this with the :x :  , can you do the honours ? 
 Yep . For posterity : As with , merging this with CI failures because they seem to be tooling related and it builds for me locally .
Paragraph (version A):
ACME allows a client to request certificate management actions using
a set of JavaScript Object Notation (JSON) messages carried over
HTTPS.  Issuance using ACME resembles a traditional CA's issuance
process, in which a user creates an account, requests a certificate,
and proves control of the domain(s) in that certificate in order for
the CA to issue the requested certificate.
Paragraph (version B):
Other than the constraint above with regard to nonces issued in
"badNonce" responses, ACME does not constrain how servers scope
nonces.  Clients MAY assume that nonces have broad scope, e.g., by
having a single pool of nonces used for all requests.  However, when
retrying in response to a "badNonce" error, the client MUST use the
nonce provided in the error response.  Servers should scope nonces
broadly enough that retries are not needed very often.
Paragraph (version B):
The server creates an account and stores the public key used to
verify the JWS (i.e., the "jwk" element of the JWS header) to
authenticate future requests from the account.  The server returns
this account object in a 201 (Created) response, with the account URL
in a Location header field.  The account URL is used as the "kid"
value in the JWS authenticating subsequent requests by this account
(see request-authentication).  The account URL is also used for
requests for management actions on this account, as described below.
Paragraph (version B):
The ACME client MAY request other formats by including an Accept
header field RFC7231 in its request.  For example, the client could
use the media type "application/pkix-cert" RFC2585 or "application/
pkcs7-mime" RFC5751 to request the end-entity certificate in DER
format.  Server support for alternate formats is OPTIONAL.  For
formats that can only express a single certificate, the server SHOULD
provide one or more "Link: rel="up"" header fields pointing to an
issuer or issuers so that ACME clients can build a certificate chain
as defined in TLS (see Section 4.4.2 of RFC8446).
Paragraph (version A):
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.  This assures that vulnerabilities in the
protocols with which the certificate is used (e.g., signing oracles
in TLS JSS15) do not result in compromise of the ACME account.
Because ACME accounts are uniquely identified by their account key
pair (see finding-an-account-url-given-a-key) the server MUST not
allow account key pair reuse across multiple accounts.
Paragraph (version B):
For this reason, it is RECOMMENDED that each account key pair be used
only for authentication of a single ACME account.  For example, the
public key of an account key pair MUST NOT be included in a
certificate.  If an ACME client receives a request from a user for
account creation or key roll-over using an account key that the
client knows to be used elsewhere, then the client MUST return an
error.  Clients MUST generate a fresh account key for every account
creation or roll-over operation.  Note that given the requirements of
finding-an-account-url-given-a-key, servers will not create accounts
with reused keys anyway.