Original text:
The JWK representation of the new key The client then encapsulates the key-change object in a JWS, signed <del> with the client's current account key (i.e., the key matching the "oldKey" value). This inner JWS then become the payload of the JWS that the client sends to the server.  The outer JWS is signed with the key pair that the the client wishes to have the server use as its account key (i.e., the key pair matching the "newKey" value).  The client sends this outer JWS in a POST request to the server's "key-change" resource. </del>  The outer JWS MUST meet the normal requirements for an ACME JWS (see request-authentication).  The inner JWS MUST meet the normal On receiving key-change request, the server MUST perform the following steps in addition to the typical JWS validation:  Check that the payload of the JWS is a well-formed JWS object (the "inner JWS") Check that the JWS protected header of the inner JWS has a "jwk" <del> field containing a key that matches a currently active account </del>  Check that the inner JWS verifies using the key in its "jwk" field the URL for the registration matching the old key Check that the "oldKey" field of the key-change object contains <del> the thumbprint of the key used to sign the inner JWS </del>  Check that the "newKey" field of the key-change object contains <del> the thumbprint of the key used to sign the outer JWS </del>  If all of these checks pass, then the server updates the corresponding registration by replacing the old account key with the

Reviewer comments:
Signing with the current account key allows servers to use the same message transport authentication that they use for other requests, simplifying the verification. Also fix two spots where we still described newKey/oldKey as thumbprints.
LGTM. I had only done that signing order to be forward-compatible with some imagined future recovery scheme, but if we decide to do that someday, that patch can differ in signature order as well as whatever else.

Revised text:
The JWK representation of the new key The client then encapsulates the key-change object in a JWS, signed  <ins> with the requested new account key (i.e., the key matching the "newKey" value). </ins> The outer JWS MUST meet the normal requirements for an ACME JWS (see request-authentication).  The inner JWS MUST meet the normal On receiving key-change 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. </ins> Check that the payload of the JWS is a well-formed JWS object (the "inner JWS") Check that the JWS protected header of the inner JWS has a "jwk"  <ins> field. </ins> Check that the inner JWS verifies using the key in its "jwk" field the URL for the registration matching the old key Check that the "oldKey" field of the key-change object contains  <ins> the current account key. </ins> Check that the "newKey" field of the key-change object contains  <ins> the key used to sign the inner JWS. </ins> If all of these checks pass, then the server updates the corresponding registration by replacing the old account key with the