Draft: draft-ietf-acme-acme

Commentary: EKR and I did a pass through the IESG comments , and found a couple minor things that were missed . 
 No , I do n't think that follows . What I 'm saying is that the way you say that is " the client " . 
 I 'm not really seeing the problem with " clients MUST NOT reuse " . In this context , " client " refers to everything on that endpoint . 
 what do you think of " clients MUST NOT intentionally reuse keys " ? The addition of " intentional " would hopefully make it clear that client software is not required to keep a copy of all past keys around to ensure it can never possibly reuse them . 
 We do n't usually treat software as having intent . I do n't see that it 's a problem to forbid the endpoint from doing it . That simply is n't a levy on some specific piece of client software to keep a list ; it 's a levy on the system of the client software and whatever is managing the keys . Happy to have a call to discuss this . 
 In the interest of making progress I 'm going to drop my objection to the " clients MUST NOT reuse " clause . I still object to " servers SHOULD scope nonces globally . " I think we should just drop that clause - it 's a very significant change to add in post - post - post - WGLC , for something that has n't been an issue in practice . 
 I 've updated the text around nonce scoping and key reuse in a way that I hope makes folks more comfortable . For nonce reuse , the text is focused on the interop problem , i.e. , making the " get a fresh nonce and retry " cycle work ; otherwise , nonce scope is left unspecified . For key reuse , I tried to be clearer about who is responsible for doing what under what circumstances . The latest push also mostly fixes the XSS issue noted in . There 's still some residual risk that a keyAuthorization will look like something else , but at least now the client 's response is required to be a keyAuthorization . 
 I 'm not really happy with this text . The requirement ought to be that you are forbidden from reusing , period . Happy to have a call to discuss , but as - is , I 'm not OK with this . 
 anyone else you need to clear this with or shall we issue the next I - D and send it to the RFC  
 next I - D and send it to the RFC  at the minimum someone needs to update the document with proposed text first . I think should also have a chance to review the changes made over the weekend . 
 Merging despite CI failure because the CI failure appears to be tooling - related . I have verified locally that the document builds correctly . 
 Excellent . Thanks for the revisions , ! Thanks everyone!Been following the thread , and I agree this is good now . Thanks !
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 that manage account keys on behalf of users SHOULD
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.