Since we know that you're writing to us, you might say,
While I'm sure we all know and recall what ISRG is, the first mention might serve as a reminder, e.g.
This starts as a list, which turns into a paragraph and immediately forgets that it was going to be a list. How about simple prose, e.g.
How about making these references a succinct list including the agreement itself rather than half the message with various style and relevance issues, e.g. something like
In my examples I've fixed various issues such as changing sense and providing abbreviations on first use only for things subsequently referenced. I'd like to fix the part about clarifying wording concerning the private key, especially the quoted word, but would need to understand the actual change.
It's pretty good as-is, but I hope my suggestions can help improve it.
I really love the plaintext summary of the changes as currently shown. A few companies have started doing that lately, and it's great. Those same companies also like to change their policies on holidays so nobody reads the emails, but that is another story...
I have no idea what your legal team has advised or required, but generally speaking every commercial product I've been involved with has approached this slightly differently:
They typically state the effective date is in 30 days, as required by the existing agreement.
They note the proper way to refute the agreement is to terminate service before that date (or choose an opt-out link that may be available for residents of a state).
They explicitly state that continued use of the service after the effective date is acceptance of the new terms.
Pretty much every product I use a customer has taken the same approach.
I'm not sure what constitutes the service though - I think it transcends the ACME protocol and includes simply possessing an ISRG certificate (as subscribers are required to maintain the confidentiality of keys and take appropriate steps if compromised).
IMHO, I would expect that Clients not bound to an email address or who have not updated their configuration to the new TOS would error out. But, I think that would break 99.9% of integrations.
FWIW, on the backend side, I've typically handled stuff like this by tracking each user-to-agreement like: (user_id, agreement_id, notification_date, signature_date). Not necessarily this data structure, but with this info. On the first agreement, and when there are explicit opt-ins, it's tracked as a signature_date; on subsequent agreements the notification_date is tracked when the notification email is sent. The goal is was always to just be able to report/research for the legal team a history of what a user agreed to, when, and how. In 20+ years of working in tech/media, I've had to generate these types of reports twice.
This is actually covered in RFC 8555 section 7.3.3 (after much back-and-forth during the standardization process):
(emphasis mine)
In other words, clients should not try to do anything with the termsOfService URL after initial sign up. The server can tell the client if it requires re-agreement.
In practice, all CAs have terms like ours that do not require re-agreement, because to do otherwise risks interruption of services. So, as long as clients implement the RFC, they should not error out.
It's possible that there are clients out there that (contra RFC) intentionally try to error out or update the account object if they see a new URL in the directory. That's buggy behavior and should be fixed. Last time we changed the Subscriber Agreement, in 2017, we shook out a few examples and they were fixed.
That's essentially what I meant/thought. I should have written "Subscribers" in my post above, not Clients, and I expect some TOS changes to be compatible – but some to not be – which would trigger the server to error out.
I've had many automated systems in the past that periodically either required a new account-key to be deployed to the production servers, or an admin would have to log into the provider's web-interface and accept a new TOS.
I didn't realize the TOS would appear in the directory... that's interesting and makes me want to explore a bit...
I received this notice at some old email addresses of mine.
Where should I log in to identify these records and update them?
I did not see an unsubscribe link in this email notice. I imagine you don't think you need one. But if you don't provide an interface to update the information and you don't provide unsubscribe link you will be reported as a spammer.
We sent this email to Let's Encrypt subscribers whose client software had submitted their email address when registering with our API. (In some cases, your Web hosting provider may be the subscriber.)
If you would like to change or remove the email address on your Let's Encrypt registration (account), you can have your client software call the /acme/acct API endpoint. If you're using a recent version of Certbot, for example, the command would be certbot update_account --email new@example.com or certbot update_account --register-unsafely-without-email.
Please be aware that removing your email address would mean you'll no longer receive important messages about your certificate(s), including renewal reminders.
If you no longer have access to your account key and would like your email address removed from an old registration, then our Privacy Policy details how you can request that we remove your data.
If you've replaced the email address on an existing registration, the old email address is gone.
If you've replaced the registration entirely, and are using a different account key now, then you would need to follow the Privacy Policy process - but with no active certificates, the only emails you would ever receive are very rare ones, like this, that apply to all subscribers.