Draft: draft-ietf-acme-acme

Commentary: This PR is collecting changes to make sure we address during the editing window . Editorial clarifications only , please . 
 Both and are also TODO 's for AUTH48 . 
 Section 7.4 says : It should say , not . Would you mind fixing this typo in this PR ? 
 Turns out the RFC editor caught that one ( see ) , so I do n't have to fix it here :) 
 LGTM
Paragraph (version A):
Except for the directory resource, all ACME resources are addressed
with URLs provided to the client by the server.  In requests sent to
these resources, the client MUST set the "url" header parameter to
the exact string provided by the server (rather than performing any
re-encoding on the URL).  The server SHOULD perform the corresponding
string equality check, configuring each resource with the URL string
provided to clients and having the resource check that requests have
the same string in their "url" header parameter.  The server MUST
reject the request as unauthorized if the string equality check
fails.
Paragraph (version B):
Except for the directory resource, all ACME resources are addressed
with URLs provided to the client by the server.  In POST requests
sent to these resources, the client MUST set the "url" header
parameter to the exact string provided by the server (rather than
performing any re-encoding on the URL).  The server SHOULD perform
the corresponding string equality check, configuring each resource
with the URL string provided to clients and having the resource check
that requests have the same string in their "url" header parameter.
The server MUST reject the request as unauthorized if the string
equality check fails.
Paragraph (version A):
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 MUST also respond to GET requests
for this resource, returning an empty body (while still providing a
Replay-Nonce header) with a status code of 204 (No Content).
Paragraph (version A):
Proxy caching of responses from the new-nonce resource can cause
clients to receive the same nonce repeatedly, leading to "badNonce"
errors.  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.
Paragraph (version B):
To get a fresh nonce, the client sends a HEAD request to the newNonce
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 MUST also respond to GET requests for this
resource, returning an empty body (while still providing a Replay-
Nonce header) with a status code of 204 (No Content).
Paragraph (version B):
Proxy caching of responses from the newNonce resource can cause
clients to receive the same nonce repeatedly, leading to "badNonce"
errors.  The server MUST include a Cache-Control header field with
the "no-store" directive in responses for the newNonce resource, in
order to prevent caching of this resource.
Paragraph (version A):
The client then encapsulates the key-change object in an "inner" JWS,
signed with the requested new account key.  This "inner" JWS becomes
the payload for the "outer" JWS that is the body of the ACME request.
Paragraph (version B):
The client then encapsulates the keyChange object in an "inner" JWS,
signed with the requested new account key.  This "inner" JWS becomes
the payload for the "outer" JWS that is the body of the ACME request.
Paragraph (version A):
Check that the payload of the inner JWS is a well-formed key-
change object (as described above).
Paragraph (version A):
Check that the "account" field of the key-change object contains
the URL for the account matching the old key (i.e., the "kid"
field in the outer JWS).
Paragraph (version A):
Check that the "oldKey" field of the key-change object is the same
as the account key for the account in question.
Paragraph (version B):
Check that the payload of the inner JWS is a well-formed keyChange
object (as described above).
Paragraph (version B):
Check that the "account" field of the keyChange object contains
the URL for the account matching the old key (i.e., the "kid"
field in the outer JWS).
Paragraph (version B):
Check that the "oldKey" field of the keyChange object is the same
as the account key for the account in question.
Paragraph (version A):
The "ACME Order Object Fields" registry lists field names that are
defined for use in ACME order objects.  Fields marked as
"configurable" may be included in a new-order request.
Paragraph (version B):
The "ACME Order Object Fields" registry lists field names that are
defined for use in ACME order objects.  Fields marked as
"configurable" may be included in a newOrder request.
Paragraph (version A):
The "ACME Authorization Object Fields" registry lists field names
that are defined for use in ACME authorization objects.  Fields
marked as "configurable" may be included in a new-authorization
request.
Paragraph (version B):
The "ACME Authorization Object Fields" registry lists field names
that are defined for use in ACME authorization objects.  Fields
marked as "configurable" may be included in a newAuthz request.