Draft: draft-ietf-acme-acme

Commentary: This simplifies both the spec and the implementation , and does not attempt to impose specific data retention policy on the CA . 
 I do n't really agree about that one . Why not delete completely the data instead of deactivating ? Why should n't a user be able to request full deletion and no retention of any of their account data ? 
 Nothing in this change prevents CAs from choosing to delete account data immediately upon deactivation , but the spec should not try to dictate policy . 
 I think this PR is fine in principal , but I have some minor concerns : If we 're going to use the field , we should prefer to use the values that are already there , namely and . Do you think there 's a semantic difference between that and what you 're proposing ? Your edits remove the guidance on what the server should return from these requests . Please add that back in . It occurs to me looking at this that the first version of authz deletion should have specified that the server MUST verify that the account is the owner of the authz before allowing it to deactivate the authz . Could you please add that while you 're editing here ? 
 Done .
Paragraph (version A):
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.
Paragraph (version A):
delete (required, boolean): The boolean value "true".
Paragraph (version A):
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".
Paragraph (version A):
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.
Paragraph (version A):
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).
Paragraph (version A):
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.
Paragraph (version B):
A client may deactivate an account by posting a signed update to the
server with a status field of "deactivated."  Clients may wish to do
this when the account key is compromised.
Paragraph (version B):
The server MUST verify that the request is signed by the account key.
If the server accepts the deactivation request, it should reply with
a 200 (OK) status code and the current contents of the registration
object.
Paragraph (version B):
Once an account is deactivated, the server MUST NOT accept further
requests authorized by that account's key.  It is up to server policy
how long to retain data related to that account, whether to revoke
certificates issued by that account, and whether to send email to
that account's contacts.  ACME does not proviate a way to reactivate
a deactivated account.
Paragraph (version A):
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".
Paragraph (version A):
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.
Paragraph (version B):
If a client wishes to relinquish its authorization to issue
certificates for an identifier, then it may request that the server
deactivate each authorization associated with that identifier.
Paragraph (version B):
The server MUST verify that the request is signed by the account key
corresponding to the account that owns the authorization.  If the
server accepts the deactivation, it should reply with a 200 (OK)
status code and the current contents of the registration object.
Paragraph (version B):
The server MUST NOT treat deactivated authorization objects as
sufficient for issuing certificates.