Original text:
6.3.1. A client may wish to change the public key that is associated with a <del> 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 new key RFC7638, base64url-encoded </del>  <del> The client signs this object with the old key pair and encodes the object and signature as a JWS.  The client then sends this JWS to the server in the "rollover" field of a request to update the registration. </del>  <del> On receiving a request to the registration URL with the "rollover" attribute set, the server MUST perform the following steps: </del>  <del> Check that the contents of the "rollover" attribute are a valid JWS </del>  <del> Check that the "rollover" JWS verifies using the account key corresponding to this registration </del>  <del> Check that the payload of the JWS is a valid JSON object </del>  <del> Check that the "resource" field of the object has the value "reg" </del>  <del> Check that the "newKey" field of the object contains the JWK thumbprint of the account key used to sign the request </del>  <del> 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 of the request JWS. </del>  <del> If the update was successful, then the server sends a response with status code 200 (OK) and the updated registration object as its body. If the update was not successful, then the server responds with an error status code and a problem document describing the error. </del>  6.3.2.

Reviewer comments:
This uses two JWS signatures to achieve the two-signature property during rollover, instead of using extra layers of encoding and embedding. It also simplifies the logic and splits it out into its own resource.

Revised text:
6.3.1. A client may wish to change the public key that is associated with a  <ins> registration in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise. </ins>  <ins> To change the key associate with an account, the client POSTs a key- change object with a "key" field containing a JWK representation of the new public key.  The JWS of this POST must have two signatures: one signature from the existing key on the account, and one signature from the new key that the client proposes to use.  This demonstrates that the client actually has control of the private key corresponding to the new public key.  The protected header must contain a JWK field containing the current account key. </ins>  <ins> On receiving key-change request, the server MUST perform the following steps in addition to the typical JWS validation: </ins>  <ins> Check that the JWS protected header container a "jwk" field containing a key that matches a currently active account. </ins>  <ins> Check that there are exactly two signatures on the JWS. </ins>  <ins> Check that one of the signatures validates using the account key from (1). </ins>  <ins> Check that the "key" field contains a well-formed JWK that meets key strength requirements. </ins>  <ins> Check that the "key" field is not equivalent to the current account key or any other currently active account key. </ins>  <ins> Check that one of the two signatures on the JWS validates using the JWK from the "key" field. </ins>  <ins> If all of these checks pass, then the server updates the corresponding registration by replacing the old account key with the new public key and returns status code 200.  Otherwise, the server responds with an error status code and a problem document describing the error. </ins> 6.3.2.