Email feedback: "Let’s Encrypt Subscriber Agreement Update"

[jsha]

@jvanasco

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.

This is actually covered in RFC 8555 section 7.3.3 (after much back-and-forth during the standardization process):

If the server has changed its terms of service since a client
initially agreed, and the server is unwilling to process a request
without explicit agreement to the new terms, then it MUST return an
error response with status code 403 (Forbidden) and type
"urn:ietf:params:acme:error:userActionRequired".

(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.