On Mon, Feb 20, 2017 at 5:47 PM, Russ Housley <[email protected]> wrote:
> > > On Feb 19, 2017, at 12:49 PM, Josh Soref <[email protected]> wrote: > > > >> 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. > > 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. > 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 protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
