I’d like to post a draft of the Let’s Encrypt Subscriber Agreement v1.1.1 here for community review before it gets schedule to take effect, ideally in late July 2016 (tentatively July 28).
I’m doing this because we had previously posted a draft of v1.1 and then pulled it before it took effect because user @rsjtdrjgfuzkfgcaught an important issue we introduced. This time around we’re going to be more proactive about soliciting community review.
If no showstopper issues are found before Tuesday July 5 then we’ll schedule this to take effect on the 28th:
First of all, thanks for pulling v1.1 and fixing the key reuse issue.
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.
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.
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.
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?
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?
@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.
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).
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!
