Original text:
registration, to allow a client to retrieve the "new-authorization" and "terms-of-service" URI <del> 6.4. </del>  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. If the update was not successful, then the server responds with an error status code and a problem document describing the error. <del> 6.5. </del>  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 may now use this in the same way as if he had gotten it from a new- registration transaction. <del> 6.6. </del>  The identifier authorization process establishes the authorization of an account to manage certificates for a given identifier.  This 201 (Created) response, with the authorization URI in a Location header field, and the JSON authorization object in the body. <del> The client needs to respond with information to complete the challenges.  To do this, the client updates the authorization object received from the server by filling in any required information in the elements of the "challenges" dictionary.  (This is also the stage where the client should perform any actions required by the challenge.) </del>  The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type, the validation is still in progress, the server MUST return a 202 (Accepted) response with a Retry-After header field. <del> 6.7. </del>  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.8. </del>  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

Reviewer comments:
Adds a little more granularity to section headings.
It should be possible for a client to delete his account / registration, and to renounce authorization for a domain. The right way to do this is probably to define a "delete" object that can be POSTed to the reg/account URI, rather than having a separate endpoint (as for certificate revocation).

Revised text:
registration, to allow a client to retrieve the "new-authorization" and "terms-of-service" URI  <ins> 6.3.1. </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. If the update was not successful, then the server responds with an error status code and a problem document describing the error.  <ins> 6.3.2. </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 may now use this in the same way as if he had gotten it from a new- registration transaction.  <ins> 6.3.3. If a client no longer wishes to have an account key registered with the server, it may request that the server delete its account by sending a POST request to the account URI containing the "delete" field. delete (required, boolean): The boolean value "true". The request object MUST contain the "resource" field as required above(with the value "reg").  It MUST NOT contain any fields besides "resource" and "delete". Note that although this object is very simple, the risk of replay or fraudulent generation via signing oracles is mitigated by the need for an anti-replay token in the protected header of the JWS. On receiving a POST to an account URI containing a "delete" field, the server MUST verify that no other fields were sent in the object (other than "resource"), and it MUST verify that the value of the "delete" field is "true" (as a boolean, not a string).  If either of these checks fails, then the server MUST reject the request with status code 400 (Bad Request). If the server accepts the deletion request, then it MUST delete the account and all related objects and send a response with a 200 (OK) status code and an empty body.  The server SHOULD delete any authorization objects related to the deleted account, since they can no longer be used.  The server SHOULD NOT delete certificate objects related to the account, since certificates issued under the account continue to be valid until they expire or are revoked. 6.4. </ins> The identifier authorization process establishes the authorization of an account to manage certificates for a given identifier.  This 201 (Created) response, with the authorization URI in a Location header field, and the JSON authorization object in the body.  <ins> 6.4.1. To prove control of the identifer and receive authorization, the client needs to respond with information to complete the challenges. To do this, the client updates the authorization object received from the server by filling in any required information in the elements of the "challenges" dictionary.  (This is also the stage where the client should perform any actions required by the challenge.) </ins> The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type, the validation is still in progress, the server MUST return a 202 (Accepted) response with a Retry-After header field.  <ins> 6.4.2. If a client wishes to relinquish its authorization to issue certificates for an identifier, then it may request that the server delete the authorization.  The client makes this request by sending a POST request to the authorization URI containing a payload in the same format as in deleting-an-account.  The only difference is that the value of the "resource" field is "authz". The server MUST perform the same validity checks as in deleting-an- account and reject the request if they fail.  If the server deletes the account then it MUST send a response with a 200 (OK) status code and an empty body. 6.5. </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.  <ins> 6.6. </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