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?
Only way I see this working with automation intact is using the registered LE account email address for TOS change notifications and thus making email registration compulsory.
LE is sending expiry infos, yes. What should the client do? It could error out or could just agree to the new terms and keep running. Option 1 will likely result in expired certificates.
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
but the question is if it just runs with the agree switches you will never know when stuff changes you might not want, that’s a problem in the automation.
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.
I believe the ACME specification is fairly agnostic to any CA's terms of service - it simply describes a way for the CA to provide a link to them if it wants to.