Agreement URL - alternate links

[icing]

Boulder seems to accept only one agreement URL for the Terms-of-Service: https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf``, but Let's Encrypt uses also other URLs for the same document, such as: https://letsencrypt.org/documents/2017.11.15-LE-SA-v1.2.pdf```. The latter one is used in https://letsencrypt.org/repository/. for example.

For interactive clients, the use the URL given in the response to an account request, this is not a problem. They simply use what boulder returns to them. For servers and other automated software, running interactive is not an option and not desirable. Here, the agreement URL needs to be configured for them by a human.

It would be useful to have boulder accept all the URLs that point to the same agreement document, especially the ones used in Let's Encrypt documentation. This will raise the success rate for automated clients and spare users repeated attempts.

(Note that it could be argued that accepting a generic ToS URL that always points to the current agreement, should suffice in signing up, but IANAL etc. etc.)

[rolandshoemaker]

Boulder provides a link to the current terms of service URL in the directory (/acme/directory) via the meta.terms-of-service (or meta.termsOfService for v2) key for this purpose.

[icing]

That is nice. However I fail to see how that helps an automated client that is configured with another URL to the same document. We are talking about humans pasting links from somewhere...

[rolandshoemaker]

I'm confused, you were originally talking about non-interactive clients?

Interactive clients should retrieve the URL from the directory and present it to users, not require the user to go find it themselves. Non-interactive clients should retrieve the URL and just echo it back (if that is what the user wants). Clients should never hardcode the URL since doing so causes these exact issues.

[rolandshoemaker]

Perhaps I misinterpreted this. If you are expecting the user to put the terms of service URL they agree to in some config file before they have even run the client once then I see the problem.

But again I don't think the solution is for the user to go and find the terms URL themselves and then just paste that in to their config. Presumably they need to parse some instructions to understand how to do this in the first place, in that case those instructions should just point them to the API directory to find that URL, not the website repository.

[icing]

To be very specific: I am talking about Apache httpd.

Users paste a URL into its configuration file and reload the server. There is no interactivity. The server runs as a daemon. The configuration file may have been edited weeks ago. The original admin has died of a horrific disease in the meantime.

Anyway..the server starts, registers an account with the configured URL. That points to the right document, is even published like that on the CA website. But boulder insists on its one and only URL and everyone is unhappy.

The thing that would be helpful here is to have an boulder-internal "equivalent" ToS URL set. That, when checking the supplied value, can proceed as if the true and correct one had been supplied.

reading your other comment in the meantime

Yes. If no one does a mistake, the world would be a better place. Unfortunately, until yesterday, someone tried to update the Apache documentation and copied the TOS URL from his browser - as shown by the Let's Encrypt site itself. He did this in good faith the the site used the correct link itself. Not an unreasonable expectation. But, sure, it was a mistake that he did not test this.

I think, eight the LE site should use exactly and only the ToS URL as acceptable to boulder or boulder should accept all URLs used by LE. The current confusion seems easily avoidable.

[rolandshoemaker]

Ah okay, I wrongly thought that we were hosting the ToS file under some API URL (which I think we did at some point in the past?) and that was the reason there was two different URLs, looking now we just have two different names for the same document under the same path on the LE website. I think the proper solution here is that we should just unify on one single name for that file.

My reluctance to change this on the boulder end is that this adds extra complexity (albeit not actually that much...) to what is currently an extremely simple code path and opens the possibility that, for whatever reason, we may end up accepting more than one version of the ToS document which (IANAL) seems bad.

[icing]

Definitely IANAL land here too. However having several links to the same doc (sometimes 30x redirects, sometimes internal, invisible redirects) seems a very common case on sites. And I think it is ok (apply IMO), and keep complexity limited, if boulder would have a set

TOS_URL= U1
TOS_ALTERNATES = U2, U3

Where everything stays as is in regard to U1, but when you receive U2 from a client POST, you exchange it internally for U1 and continue as if U1 had been supplied (and only ever store U1). Again, IANAL and such, but TOS_ALTERNATE should point to the same PDF (or a copy of it). So I do not see any contractual difference here.

Just how I would do it, but I am not in your shoes... :)

[jsha]

My preference is to consolidate on a single, long-term URL for the terms. Will consult our Ls.

[rolandshoemaker]

We consolidated on one URL.