Change:
What advantage does including the old key provide?
Having the new key sign over the field makes the hand-over mutual -- the old key blesses the new key by signing over the JWS and the new key accepts by signing over the thumbprint. Basically, the field is acting as an identifier for the registration for purposes of the new key's acceptance of the hand-over. Note that this is well-defined because the server is required to only have one registration for a given key-pair (it MUST return a 409/Conflict if there's an attempt to duplicate).
Account keys should change over time to improve security. We should have a way to change the key associated with an account with changing anything else about the account. Something liike: Post: /rotate-key { "key": { / JWK key / } } Note: The request should be signed with the old key. All authorizations should remain with the account. If there are any requests being validated then they should still use the old key (as specified by the oriignal authorization request.

Discussion:
6.4. <ins> A client may wish to change the public key that is associated with a registration, e.g., in order to mitigate the risk of key compromise. To do this, the client first constructs a JSON object representing a request to update the registration: The string "reg", indicating an update to the registration. The JWK thumbprint of the old key RFC7638, base64url-encoded The client signs this object with the new key pair and encodes the object and signature as a JWS.  The client then sends this JWS to the server in the "newKey" field of a request to update the registration. On receiving a request to the registration URL with the "newKey" attribute set, the server MUST perform the following steps: Check that the contents of the "newKey" attribute are a valid JWS Check that the "newKey" JWS verifies using the key in the "jwk" header parameter of the JWS Check that the payload of the JWS is a valid JSON object Check that the "resource" field of the object has the value "reg" Check that the "oldKey" field of the object contains the JWK thumbprint of the account key for this registration If all of these checks pass, then the server updates the registration by replacing the old account key with the public key carried in the "jwk" header parameter of the "newKey" JWS object. 6.5. </ins> Once a client has created an account with an ACME server, it is possible that the private key for the account will be lost.  The recovery contacts included in the registration allows the client to

may now use this in the same way as if he had gotten it from a new- registration transaction. <del> 6.5. </del> <ins> 6.6. </ins> The identifier authorization process establishes the authorization of an account to manage certificates for a given identifier.  This

the validation is still in progress, the server MUST return a 202 (Accepted) response with a Retry-After header field. <del> 6.6. </del> <ins> 6.7. </ins> The holder of an authorized key pair for an identifier may use ACME to request that a certificate be issued for that identifier.  The

the certificate URI does not yield one, then the client may initiate a new-certificate transaction to request one. <del> 6.7. </del> <ins> 6.8. </ins> To request that a certificate be revoked, the client sends a POST request to the ACME server's revoke-cert URI.  The body of the POST