Let's Encrypt Subscriber Agreement v1.1.1

First of all, thanks for pulling v1.1 and fixing the key reuse issue. :slight_smile:

I came across a rather cosmetic wording issue, and as it seems that this thread is intended to also cover less drastic issues:

1. Definitions and Terms
[...]
"Key Pair" – [...] and (ii) even while knowing or possessing one key (e.g., the Public Key), it is computationally difficult or infeasible to discover the other key (e.g., the Private Key). [...]

This wording - at least to me as non-native speaker - seems to imply that possession of the private key must not directly lead to possession of the public key, while only the inverse is intended to be required. Of course, with context, the intended scope becomes obvious.

1 Like

Hi @josh , did you see the last message of Kathleen Wilson in https://bugzilla.mozilla.org/show_bug.cgi?id=1204656 ?

More people commented in the discussion, so I think the discussion is not yet ready to be closed. The CA needs to drive the Q&A in the discussion to closure, by responding to the questions and concerns that are raised.

Did you (or someone else from LE/ISRG) intent to answer Peter Kurrasch in Redirecting to Google Groups ?

in paras 3.5, 3.6, 3.7, 3.8, 3.9

You warrant to ISRG and the public-at-large, and You agree, that You will ...

In earlier paras it is " You warrant to ISRG and the public-at-large that" you have (in the past) and " You agree that" you will (in the future) ... which does make sense.

However, in theses paras, assuming that you warrant means you "officially affirm or guarantee.", then the "and You agree" seems superfluous.

Thanks for the feedback. We’ve considered it and decided to move forward with v1.1.1 with no further changes. Both comments refer to potentially minor wording changes and we’d prefer to keep the current wording.

3 Likes

Will accounts who have accepted the existing TOS need to re-auth to this TOS… or will they automatically consent through continued use?

I ask this because automated systems are involved.

1 Like

@jvanasco: Existing accounts will automatically consent through continued use, so automated systems won’t have an interruption in service.

4 Likes

wonderful! it would be good to include whether or not that will happen on announcements like this.

1 Like

Our automated system got bit by this today (it generates new keypairs frequently instead of reusing registrations long-term, which was the workaround we were suggested to use to avoid “bad replay nonce” errors).

Is there some feed we should have been monitoring that would have told us ahead of time that we would need to update to the new agreement before today? Was the new agreement URL even available before today?

1 Like

There was an e-mail sent on July 9th announcing the update:

Let's Encrypt Subscriber,
We're writing to let you know that we are updating the Let's Encrypt Subscriber
Agreement, effective August 1, 2016. You can find the updated agreement
(v1.1.1) as well as the current agreement (v1.0.1) in the "Let's Encrypt Subscriber Agreement" section of the following page:
Policy and Legal Repository - Let's Encrypt
Thank you for helping to secure the Web by using Let's Encrypt.

  • The Let's Encrypt Team

The agreement was published on the abovementioned URL along with the diff from previous version.

Unfortunately I hadn't seen any announcement regarding the time when this new version would become default and be enforced (except only the date - August 1st). It was also unclear whether the new version would be accepted before it comes into effect.
At around 12:00 GMT v1.0.1 still seemed to be in effect, so in the end we ended up with broken system as well for some time before we noticed it's been done already. Maybe I just missed a roadmap published somewhere else?

1 Like

There is some discussion of this question at How to get URL to subscriber agreement before registering (maybe that will be helpful to you).

1 Like

@glasser @Majkl I’m sorry to hear that this caused you problems. The ACME protocol (as discussed in the thread @schoen linked to) provides enough information during the registration flow that you do not need to hardcode the ToS string. Compliant clients will not encounter outages from a ToS change if they use this method instead of hardcoding the URL.

I definitely recommend that approach moving forward! Again, apologies for the trouble. We will likely change the way we roll out a ToS update in the future to account for some of the buggy client implementations.

@cpu While that’s a great technical solution, our legal folks say that if we’re actually considering the protocol agreement as a legal agreement, then we shouldn’t write code to automatically agree to agreements we may not have read.

What email address should have received the message that @Majkl mentioned? It’s possible that we don’t have the right address signed up (maybe it just goes to the person who originally implemented our LE integration or something).

I also think that message should be a little more explicit about saying “On this date, new automatically-generated registrations will be required to specify the new agreement’s URLs.” or something.

2 Likes

While that's a great technical solution, our legal folks say that if we're actually considering the protocol agreement as a legal agreement, then we shouldn't write code to automatically agree to agreements we may not have read.

I can understand why that would be challenging from the perspective of your legal team. My response omitted the implied step where the ToS is retreived and the text is presented to a human being to agree to. This is imperative regardless of whether the ToS string is hard-coded or not. Your code should only be "automatic" in the sense that it shouldn't have to rely on a hardcoded agreement URL.

What email address should have received the message that @Majkl mentioned? It's possible that we don't have the right address signed up (maybe it just goes to the person who originally implemented our LE integration or something).

This would be the email address that was provided with your Let's Encrypt account registration. It is an optional field and so its possible whoever set up your integration's account did not provide it. This can be updated after the fact by many ACME clients (e.g. Certbot's --update-registration flag).

I also think that message should be a little more explicit about saying "On this date, new automatically-generated registrations will be required to specify the new agreement's URLs." or something.

Agreed - there is definitely room for improvement in our process here. We will certainly try to make this communication clearer in the future. Thanks for your patience.

@cpu Ah, I don’t think that would make sense for our use case. We are a hosting provider offering automatic SSL cert creation and maintenance as a feature for our users. We are comfortable centralizing ToS agreement within our organization (ie, we don’t think our individual customers need to individually agree to it; we don’t actually provide them with the cert private keys directly), but our service does run automatically as prompted by our users without human intervention by employees of our company.

So I don’t think that what you’re suggesting works here: we neither want to auto-agree to all ToSes, nor do we want to be paged at the moment that the server’s ToS rolls over and have to engage lawyers at that point. We’d like to have a human read the new ToS, decide it’s appropriate, and add the URL to the list of accepted ToSes before it becomes the official one, not after (which causes an outage for our users, who don’t generally have to worry about the ToS for themselves).

@glasser Aha - thanks for the further clarification. That's helpful. What you're describing matches our own guidance for integrator's and is definitely a use case we need to be considering.

We'd like to have a human read the new ToS, decide it's appropriate, and add the URL to the list of accepted ToSes before it becomes the official one, not after (which causes an outage for our users, who don't generally have to worry about the ToS for themselves).

That's valuable feedback - I can't promise anything but I will start a discussion internally before we update the ToS again to see if there's something we can do to make this smoother for integrators in the future.

Ah, thanks @cpu! I realize I hadn't actually read Integration Guide - Let's Encrypt (though I suspect the engineer who originally implemented our integration has).

It says:

We will be providing a low-volume developers’ mailing list to receive news of important changes like the above (watch this space).

Does that exist yet?

We will be providing a low-volume developers’ mailing list to receive news of important changes like the above (watch this space).

Does that exist yet?

There is client-dev@letsencrypt.org but I'm not sure its the right list for this (despite the name). It predates the Let's Encrypt client -> Certbot rename/ownership change and is primarily Certbot related discussion (AFAIK). @roland and I were talking about sorting out this TODO yesterday as a step towards helping smooth the communication related to these sorts of changes.

Yup! There is a new list, integrators@letsencrypt.org (https://groups.google.com/a/letsencrypt.org/forum/#!forum/integrators), which we are going to start using for better interacting with client developers and large scale integrators as well as a place for announcements etc that may affect their work.

I haven’t gotten around to sending out messages to developers inviting them to take part but if you want to sign up yourself and/or let others know feel free!

@roland Neat! Note that it looks like people have to be invited to join right now (there’s no “join” button).

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