How should the agreement to the terms of service work? Using a flag like --agree-tos seems inappropriate as terms may change in the future. Passing the URL seems like a reasonable implementation, but that would break automation. How to notify server owners that the certificate can’t be renewed due to an outdated ToS agreement then?
Maybe make TOS a publicly facing web page on letsencrypt.org domain and have the letsencrypt client just check for changes to that url link to determine if the TOS page has changed and the notify accordingly ?
But yeah I see the dilemma if the TOS changes are not what the end user likes and wants out, what does the LE client do hmmm
or just do what some servcies do, continued usage = agreement to new TOS and email notify of TOS changes
Yes, our current Subscriber Agreement has language stating that notification of updates will be sent by email if you provide one, and continued use indicates agreement. This was a tricky decision, but we wound up deciding that requiring a manual re-agreement to terms would be too likely to break people’s automated renewals, which would be bad.
In practical terms that means that, once an account key is registered and the operator has agreed to the Subscriber Agreement, you don’t need to prompt them to re-agree.
This is a huge win for client usability. I’ve seen too many products crippled by their legal departments who ruined the user experience or the feasibility of killer features. Glad that this is not the case with Let’s Encrypt. As a client developer, I can fully appreciate what this makes possible for users.
There are various reasons people might not want to provide an email, primarily pseudonymity. Since Let’s Encrypt only certifies your control of a domain name, not your control of an email address, an email address is not required. However, we try very hard in the client to encourage people to provide one, and spell out the consequences: not providing an email means missing out on communications.
Do you think we need language for that in the ACME specification? Assumptions based on a single ToS for a generic protocol / client are dangerous. Since software can’t assume that, we would either need a whitelist (breaking automation for other servers not whitelisted), an explicit flag, language in the specification or an API endpoint to ask if such a phrase is present in the ToS.