Draft: draft-ietf-acme-acme

Commentary: Since resources that provide nonces ca n't be cacheable , let 's isolate nonce priming into one non - cacheable resource so that we do n't affect the cacheability of other resources . Note : This should replace 
 This generally LGTM 
 The new - nonce endpoint in defines a new endpoint which returns information just in headers , but with a 200 response code . I feel this would be more appropriate as a 204 No Content response code . I 'm not sure what the approach to making this sort of change is . Should I create this change as a PR ? 
 A PR and a small note to the mailing list is probably the best approach . I 'm not an HTTP status lawyer but it seems like 204 is the more - appropriate choice in this context and seems to agree with you : I would : +1 : the PR to change to 204 for :-)
Paragraph (version A):
An ACME server MUST include a Replay-Nonce header field in each
successful response it provides to a client, with contents as
specified below.  In particular, the ACME server MUST provide a
Replay-Nonce header field in response to a HEAD request for any valid
resource.  (This allows clients to easily obtain a fresh nonce.)  It
MAY also provide nonces in error responses.
Paragraph (version B):
An ACME server provides nonces to clients using the Replay-Nonce
header field, as specified below.  The server MUST include a Replay-
Nonce header field in every successful response to a POST request,
and SHOULD provide it in error responses as well.
Paragraph (version A):
When a server rejects a request because its nonce value was
unacceptable (or not present), it SHOULD provide HTTP status code 400
(Bad Request), and indicate the ACME error code
"urn:ietf:params:acme:error:badNonce".
Paragraph (version B):
When a server rejects a request because its nonce value was
unacceptable (or not present), it SHOULD provide HTTP status code 400
(Bad Request), and indicate the ACME error code
"urn:ietf:params:acme:error:badNonce".  An error response with the
"badNonce" error code MUST include a Replay-Nonce header with a fresh
nonce.  On receiving such a response, a client SHOULD retry the
request using the new nonce.
Paragraph (version A):
For the singular resources above ("directory", "new-registration",
"new-application", "revoke-certificate", and "key-change") the
resource may be addressed by multiple URIs, but all must provide
equivalent functionality.
Paragraph (version B):
The server MUST provide "directory" and "new-nonce" resources.
Paragraph (version B):
For the singular resources above ("directory", "new-nonce", "new-
registration", "new-application", "revoke-certificate", and "key-
change") the resource may be addressed by multiple URIs, but all must
provide equivalent functionality.
Paragraph (version B):
Before sending a POST request to the server, an ACME client needs to
have a fresh anti-replay nonce to put in the "nonce" header of the
JWS.  In most cases, the client will have gotten a nonce from a
previous request.  However, the client might sometimes need to get a
new nonce, e.g., on its first request to the server or if an existing
nonce is no longer valid.
Paragraph (version B):
To get a fresh nonce, the client sends a HEAD request to the new-
nonce resource on the server.  The server's response MUST include a
Replay-Nonce header field containing a fresh nonce, and SHOULD have
status code 200 (OK).  The server SHOULD also respond to GET requests
for this resource, returning an empty body (while still providing a
Replay-Nonce header).
Paragraph (version B):
Caching of responses from the new-nonce resource can cause clients to
be unable to communicate with the ACME server.  The server MUST
include a Cache-Control header field with the "no-store" directive in
responses for the new-nonce resource, in order to prevent caching of
this resource.