Subject: [Acme] Allowing for consistent handling of ToS re-agreement

From: Zach Shepherd <[email-masked]>
Date: Wed, 22 Mar 2017 22:19:27 +0000

The following feedback is based on 8010a31 (current HEAD of master).

Section 7.3.1, Changes of Terms of Service, states the following:

"As described above, a client can indicate its agreement with the CA’s terms of service by setting the “terms-of-service-agreed” field in its account object to “true”.

"If the server has changed its terms of service since a client initially agreed, and the server is unwilling to process a request without explicit agreement to the new terms, then it MUST return an error response with status code 403 (Forbidden) and type “urn:ietf:params:acme:error:userActionRequired”. This response MUST include a Link header with link relation “terms-of-service” and the latest terms-of-service URL.

"The problem document returned with the error MUST also include an “instance” field, indicating a URL that the client should direct a human user to visit in order for instructions on how to agree to the terms."

I realize that this has been debated extensively and largely agree with the conclusions from [1], but I think there are disadvantages to having the ToS URL provide instructions for the human user to agree to the new term. The main concern I have with [1] is that there may not be a clear way for the human user to authenticate with the CA to click an "Accept" button if the ACME server hasn't needed to use the external-account-binding functionality for some other reason.

I think a relatively small change could address this: associate a timestamp with terms-of-service-agreed, and include it as a read-only part of the account object.

In this way, it is easy for a client to allow the human user to re-accept terms in a standard way (following the same pattern the client would use for any other account update), causing the server to update the associated timestamp. This provides consistency between ACME servers.

This requires that the server track when clients have agreed to updated terms of service, which is only incrementally more work than storing a boolean (and is something a server may want to track anyway).

This still fully supports the notion of "auto updating" terms of service.

This could still support a human user clicking an "Accept" button, which could trigger an out-of-band update to the timestamp (and the permissibility of this could be emphasized with a MAY).

This adds minimal additional complexity to the protocol.

Regards,
Zach Shepherd

1 - https://mailarchive.ietf.org/arch/msg/acme/c-wycMyvyX0Jkk7NS0Lfxj6Z0GY