How to test "Changes of Terms of Service"?

Client dev
1

While developing an ACME client using certbot’s python-acme, I realized that it is not ready to receive an “userActionRequired” error, since the class “Error” (on the file certbot/acme/acme/messages.py) would ignore the field “instance” described in the section 7.3.4 of the RFC (https://tools.ietf.org/html/draft-ietf-acme-acme-13#section-7.3.4), making it completely inaccessible for anyone using this library. Although not the perfect solution, but patching python-acme would fix it. The problem is that there is no where to test it against. I’m not a Go developer, but I don’t seem to find any implementation of the “userActionRequired” error anywhere in the Boulder server code.

Even though the instructions at the “instance” url are obscure and have to be followed by the user, I would like to have most features of my ACME client automated, but the “Changes of Terms of Service” seems to only exist in the RFC draft.

So the question is, how can it be tested? Is it going to be implemented in Boulder/certbot? Or am I missing something here?

Thank you in advance!

2

Hi,

Here are a response from let's encrypt years ago..

Also, you could compare the versions of agreement, since every version is published in different names.

Thank you

Thank you

3

:wave: Hi @jrc, great question, thank you.

Boulder doesn't implement this because Let's Encrypt has specifically written our user agreement such that by agreeing at the time of account creation you are automatically opted-in to future updates (that you will be notified about via the account contact address). I believe this is extremely common practice with regards to ToS contents but I'm most definitely not a lawyer.

My memory of the discussion within the working group was that the "userActionRequired" error for a terms of service change was a compromise allowed into the spec to alleviate the concerns of folks that fundamentally disagree with the practice of a terms-of-service document being changed but not requiring some manual action from the subscriber to "re-agree".

We have no plans to implement this in Boulder.

I would consider accepting a PR to the Pebble ACME server to allow changing the agreement URL at runtime, returning "userActionRequired" problems to clients afterwards. While Let's Encrypt won't be using this it seems conceivable another ACME server might and I think it would be a gesture of good will to the larger community to offer a ACME test server that can be used for this protocol feature. Unfortunately I don't think I would be able to prioritize implementing it myself. You mention not being a Go developer, want to give it a shot? :grin:

Hope that helps clarify!

2 Likes
4

Thank you very much @cpu !!

Cool, it is really clear for me now.

I might give it a shot at some point, but it is also not priority.

Cheers!

1 Like
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.