Change:
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 . NAME Would you mind fixing this typo in this PR?
NAME Turns out the RFC editor caught that one (see ), so I don't have to fix it here :)
LGTM

Discussion:
unauthorized. Except for the directory resource, all ACME resources are addressed <del> 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. </del> <ins> 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. </ins> 6.4.1.

new nonce, e.g., on its first request to the server or if an existing nonce is no longer valid. <del> 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). </del> <ins> 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). </ins> <del> Proxy caching of responses from the new-nonce resource can cause </del> <ins> Proxy caching of responses from the newNonce resource can cause </ins> clients to receive the same nonce repeatedly, leading to "badNonce" errors.  The server MUST include a Cache-Control header field with <del> the "no-store" directive in responses for the new-nonce resource, in </del> <ins> the "no-store" directive in responses for the newNonce resource, in </ins> order to prevent caching of this resource. 7.3.

this request and its signature, and indicates the old key holder's assent to the rollover request. <del> To create this request object, the client first constructs a key- change object describing the account to be updated and its account </del> <ins> To create this request object, the client first constructs a keyChange object describing the account to be updated and its account </ins> key: The URL for the account being modified.  The content of this field

The JWK representation of the old key. <del> The client then encapsulates the key-change object in an "inner" JWS, </del> <ins> The client then encapsulates the keyChange object in an "inner" JWS, </ins> 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.

old key.  The "outer" JWS represents the current account holder's assent to this request. <del> On receiving key-change request, the server MUST perform the following steps in addition to the typical JWS validation: </del> <ins> On receiving keyChange request, the server MUST perform the following steps in addition to the typical JWS validation: </ins> Validate the POST request belongs to a currently active account, as described in message-transport.

Check that the inner JWS verifies using the key in its "jwk" field. <del> Check that the payload of the inner JWS is a well-formed key- change object (as described above). </del> <ins> Check that the payload of the inner JWS is a well-formed keyChange object (as described above). </ins> Check that the "url" parameters of the inner and outer JWSs are the same. <del> Check that the "account" field of the key-change object contains </del> <ins> Check that the "account" field of the keyChange object contains </ins> the URL for the account matching the old key (i.e., the "kid" field in the outer JWS). <del> Check that the "oldKey" field of the key-change object is the same </del> <ins> Check that the "oldKey" field of the keyChange object is the same </ins> as the account key for the account in question. Check that no account exists whose account key is the same as the

The "ACME Order Object Fields" registry lists field names that are defined for use in ACME order objects.  Fields marked as <del> "configurable" may be included in a new-order request. </del> <ins> "configurable" may be included in a newOrder request. </ins> Template:

The "ACME Authorization Object Fields" registry lists field names that are defined for use in ACME authorization objects.  Fields <del> marked as "configurable" may be included in a new-authorization request. </del> <ins> marked as "configurable" may be included in a newAuthz request. </ins> Template:

MitM registers account key pair B <del> Legitimate domain holder sends a new-order request signed using </del> <ins> Legitimate domain holder sends a newOrder request signed using </ins> account key A MitM suppresses the legitimate request but sends the same request