Draft: draft-ietf-acme-acme

Commentary: This PR is a re - do of . It only removes recovery ; it does not add the " account - mgmt " metadata item . 
 LGTM 
 We removed recovery in . If we refactor roll - over as proposed in , however , recovery can be done much more simply , at least if you assume the client is provisioned with a MAC key ( possibly out of band ) . 
 Agreed at IETF 96 that we will not specify recovery . Instead , we will add some guidance for CAs as to how to handle loss of account keys .
Paragraph (version A):
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
recover from this situation, as long as it still has access to these
contacts.
Paragraph (version A):
By "recovery", we mean that the information associated with an old
account key is bound to a new account key.  When a recovery process
succeeds, the server provides the client with a new registration
whose contents are the same as base registration object - except for
the "key" field, which is set to the new account key.  The server
reassigns resources associated with the base registration to the new
registration (e.g., authorizations and certificates).  The server
SHOULD delete the old registration resource after it has been used as
a base for recovery.
Paragraph (version A):
In addition to the recovery mechanisms defined by ACME, individual
client implementations may also offer implementation-specific
recovery mechanisms.  For example, if a client creates account keys
deterministically from a seed value, then this seed could be used to
recover the account key by re-generating it.  Or an implementation
could escrow an encrypted copy of the account key with a cloud
storage provider, and give the encryption key to the user as a
recovery value.
Paragraph (version A):
The client requests recovery by asking that the server send a message
to one of the contact URIs registered for the account.  That message
indicates some action that the server requires the client's user to
perform, e.g., clicking a link in an email.  If the user successfully
completes the server's required actions, then the server will bind
the account to the new account key.
Paragraph (version A):
To initiate recovery, the client sends a POST request to the server's
recover-registration URI, with a body specifying which registration
is to be recovered.  The body of the request MUST be signed by the
client's new account key pair.
Paragraph (version A):
The URI for the registration to be recovered.
Paragraph (version A):
If the server agrees to attempt recovery, then it creates a new
registration resource containing a stub registration object.  The
stub registration has the client's new account key and contacts, but
no authorizations or certificates associated.  The server returns the
stub contact in a 201 (Created) response, along with a Location
header field indicating the URI for the new registration resource
(which will be the registration URI if the recovery succeeds).
Paragraph (version A):
After recovery has been initiated, the server follows its chosen
recovery process, out-of-band to ACME.  While the recovery process is
ongoing, the client may poll the registration resource's URI for
status, by sending a POST request with a trivial body
({"resource":"reg"}).  If the recovery process is still pending, the
server sends a 202 (Accepted) status code, and a Retry-After header
field.  If the recovery process has failed, the server sends an error
code (e.g., 404), and SHOULD delete the stub registration resource.
Paragraph (version A):
If the recovery process has succeeded, then the server will send a
200 (OK) response, containing the full registration object, with any
necessary information copied from the old registration).  The client
may now use this in the same way as if he had gotten it from a new-
registration transaction.
Paragraph (version A):
The account recovery processes described in account-recovery allow
authorization to be transferred from one account key to another, in
case the former account key pair's private key is lost.  ACME needs
to prevent these processes from being exploited by an attacker to
hijack the authorizations attached to one key and assign them to a
key of the attacker's choosing.
Paragraph (version A):
The provisioning process needs to ensure that only the account key
holder ends up with information that is useful for recovery.  The
recovery process needs to assure that only the (now former) account
key holder can successfully execute recovery, i.e., that this entity
is the only one that can choose the new account key that receives the
capabilities held by the account being recovered.
Paragraph (version A):
Account recovery uses both the ACME channel and the contact channel.
The provisioning process is only visible to an ACME MitM, and even
then, the MitM can only observe the contact information provided.  If
the ACME attacker does not also have access to the contact channel,
there is no risk.
Paragraph (version A):
If the server requires a user to click a link in a message sent to
a contact address, then the contact channel will need to ensure
that the message is only available to the legitimate owner of the
contact address.  Otherwise, a passive attacker could see the link
and click it first, or an active attacker could redirect the
message.
Paragraph (version A):
If the server requires a user to respond to a message sent to a
contact address containing a secret value, then the contact
channel will need to ensure that an attacker cannot observe the
secret value and spoof a message from the contact address.
Paragraph (version A):
In practice, many contact channels that can be used to reach many
clients do not provide strong assurances of the types noted above.
In designing and deploying recovery schemes, ACME servers operators
will need to find an appropriate balance between using contact
channels that can reach many clients and using contact-based recovery
schemes that achieve an appropriate level of risk using those contact
channels.