Subject: [Acme] terms-of-service boolean

From: Josh Soref <[email-masked]>
Date: Sun, 19 Feb 2017 12:49:17 -0500

> terms-of-service-agreed (optional, boolean):

This should really be a URL, not a boolean.

> : Including this field in a new-account request,
> with a value of true, indicates the client's agreement with the terms of service.
> This field is not updateable by the client.

Consider this flow:

1. user starts ACME client
2. ACME client retrieves metadata from acme server which includes url of ToS
3. ACME server is updated with new ToS
4. ACME client presents user w/ ToS from 2
5. user accepts ToS from 4
6. ACME client makes request to acme server with "true" based on 5/4/2
7. ACME server thinks the user has accepted ToS from 3.

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Feb 2017 17:47:57 -0500

> On Feb 19, 2017, at 12:49 PM, Josh Soref <[email-masked]> wrote:
> 

I am not sure that one ought to expect major changes in the term-of-service without there being significant changes in the CA.  However, you suggest does ensure that the client is accepting the same terms-of-service that the server is offering.

Another approach would be to hash the webpage provided by the server.

Russ

---

From: Richard Barnes <[email-masked]>
Date: Mon, 20 Feb 2017 19:49:17 -0500

On Mon, Feb 20, 2017 at 5:47 PM, Russ Housley <[email-masked]> wrote:

> I am not sure that one ought to expect major changes in the
> term-of-service without there being significant changes in the CA.
> However, you suggest does ensure that the client is accepting the same
> terms-of-service that the server is offering.
>

This was pretty extensively litigated in the working group.  The consensus
was: In practice, CAs structure their ToS so that they can make unilateral
changes.  If for some reason a CA does need re-agreement, it can use the
"userActionRequired" error code.

I'm not sure this particular edge case was considered.  But TBH, it seems
like there are a few mitigations here short of changing the protocol:

- The client can ping the ToS URL immediately before 6 to see if it has
changed
- The server can simply not change the ToS URL, and present the most
current version of its ToS there

If you want advisory text to point to these risks / mitigations, by all
means file a PR.  But given the way ToS are structured in practice, this
seems unlikely to be an issue.

--Richard

>
> Russ
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>