On 09/24/2016 06:03 PM, Hugo Landau wrote: >> Very specifically, I am trying to make life easier for clients that >> hardcode the agreement URL. > How can hardcoding the URL ever be legitimate?
Sorry, this was one of those worst-case typos. It should have read: "Very specifically, I am *not* trying to make life easier for clients that hardcode the agreement URL." I agree that that's not legitimate. > You've also mentioned that agreement URI updates can never be automated, > so having an in-band mechanism for agreement *update* (as opposed to > initial assent at registration time) is pointless, but this isn't true. > If a client user is informed of a new URI before it is deployed via an > out-of-band channel, they may be able to configure their clients ahead > of time to recognise and assent to it whenever they do see it. This > could be automated if a large number of client instances are used; the > only non-automatable work is a per-URI human-triggered approval. The most likely out-of-band channel is email, right? So the CA would send out email informing their customers that there's a new ToS, and the customer needs to explicitly agree to it in the next N days, or they will be unable to use the service. There are a couple of options the CA could ask their customer to do for the next step: a) Click a link in the email, read the new ToS, and click "Agree" at the bottom. b) Click a link in the email, read the new ToS, and copy and paste the new ToS URL into the customer's ACME client config. I think (a) is both more user-friendly and more likely to be what a CA would actually implement. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
