Subject: [Acme] Terms of service agreement changes

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sat, 6 Aug 2016 11:30:25 -0700

Let's Encrypt recently did its first update of its Subscriber Agreement,
and ran into some incompatibility. The current spec makes it seem like
the client should update the registration object whenever the Subscriber
Agreement (known in ACME as terms-of-service) changes.

However, early in drafting LE's Subscriber Agreement, we realized that
if we required human approval of Subscriber Agreement changes, that
would break auto-renewal. So our Subscriber Agreement says that updates
automatically apply to existing users after a notice period.*

The existing ACME terms-of-service flow is an awkward hold-over from
when we treated the new-reg URL as the entry point. Currently you create
an account, get told the ToS URL, and update the account object with
that URL. That then gets stored as a property of the registration object
forever.

Now that we have the directory object, and it contains a
terms-of-service URL, we can say that for CAs with a terms-of-service
URL, you must agree before you can create an account. We can have an
"agree": true field in the new-reg POST to signal agreement to the
current terms-of-service from the directory object. Then the
terms-of-service URL doesn't need to be a permanent part of the
registration object, and we can avoid ambiguity over whether and when
clients need to update or check it.

What do you think?

*As much as I dislike these types of agreement as a consumer, I think
it's the only reasonable approach to allow robust automatic issuance

---

From: Hugo Landau <[email-masked]>
Date: Sun, 7 Aug 2016 13:34:28 +0100

> clients need to update or check it.

I don't think we need to get rid of the URI-based approach. Though this
is rather asinine, '"agree": true' would be vulnerable to race
conditions between retrieving the directory and registering (...).

Here are some more options:

1. Add a "agreement-valid": bool field to the registration object 
   which indicates whether the current agreement value is valid even
   if it doesn't match the ToS valid.

2. Have the server return a ToS link value equalling the old (but still
   acceptable) agreement value when returning registration data.
   Registrations with a no-longer-acceptable agreement value or
   no agreement set get the current ToS link value.

3. Update the agreement URI for all accounts when updating agreements,
   so that the agreement URI always matches the Link-advertised URI
   if the agreement is valid. Not really feasible if there's a notice
   period, though, assuming the notice period doesn't apply to new
   registrations.

I think option 1 is probably the best, but I may be biased in favour of
what's easiest to implement in my own client.

(In the LE case specifically, I wonder if the URI needs to change at all
if the agreement is designed so that updates apply automatically. Each
version should probably have an immutable archival URI, but a single
fixed URI could point to the current version. Still, this needs to be
worked out in the spec.)

Hugo Landau

---

From: Richard Barnes <[email-masked]>
Date: Sun, 7 Aug 2016 19:07:35 -0700

> fixed URI could point to the current version. Still, this needs to be

I agree with Hugo that it seems like there's still value in having the URI
in the registration object.  It seems like there's probably requirements on
both sides here:

- The CA needs to be able prompt re-agreement
- The CA needs to be able to update the terms/SA URL without prompting
re-agreement

We can meet both of these if, as Hugo notes, we let the CA update the
agreement URI in the registration object.  Then the client can compare the
URI in the object to the URI in the directory / link header, and if they
differ, prompt for re-agreement (or deactivate the registration).

Spec-wise, I think we would just want to add a note that the server can
update the agreement URL in the registration object in cases where
agreement with the old implies agreement with the new (e.g., if they
represent the same document and just the URL changed).  We might also want
an "agreementRequired" error code that the server can use to explicitly
prompt for re-agreement.

--Richard

>
> Hugo Landau
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Niklas Keller <[email-masked]>
Date: Mon, 8 Aug 2016 12:25:46 +0200

> - The CA needs to be able prompt re-agreement

How is this supposed to work with automation? Just break it?

I guess most client implementations will just agree with the terms then and
see a "I have not been stopped" as further agreement.

Regards, Niklas

---

From: Richard Barnes <[email-masked]>
Date: Mon, 8 Aug 2016 09:33:38 -0700

On Mon, Aug 8, 2016 at 3:25 AM, Niklas Keller <[email-masked]> wrote:

>> I agree with Hugo that it seems like there's still value in having the
>> URI in the registration object.  It seems like there's probably
>> requirements on both sides here:
>>
> I guess most client implementations will just agree with the terms then
> and see a "I have not been stopped" as further agreement.
>

For better or worse, the state of the industry right now is that not
everything can be fully automated all of the time.  Sometimes CAs need for
the tools to get a human in the loop for an updated agreement.

Given that that's the state, the only question here is whether this
semantic should be expressed in the protocol.  A CA can always just refuse
to take any action until a subscriber agrees to the new terms.  This
proposal would just let it happen cleanly, with the client being aware of
what the issue is.

--Richard

---

From: Ron <[email-masked]>
Date: Tue, 9 Aug 2016 03:16:59 +0930

> - The CA needs to be able to update the terms/SA URL without prompting

I think there's another important factor there we should be explicit
about too:

 - The end user has to find the new terms are actually still acceptable
   to them.

Which means the client software does need to always notify them that
they've changed, even if that doesn't provoke an immediate hard failure.

A change in the ToS could be anything from "our lawyers said we need to
insert this magic word in paragraph 4 that doesn't change the spirit of
this agreement in any way" to "by silently ignoring this change you
hereby agree to donate your first-born's organs to my sick cousin ..."

So whatever we do, it does need to be unambiguous about what you have
or haven't (yet) agreed to.

> differ, prompt for re-agreement (or deactivate the registration).

This is basically what the client code that I have currently does.
It records the URI of the ToS that was agreed to, and if that later
changes in the CA header it then complains about that, asking you to
explicitly agree to the new terms again.

Having a way for the CA to signal that there is a grace period where the
old terms will still apply, and automated renewals will be accepted if
they proceed, might be useful - but that could also be implicit  ie.
the client just proceeds anyway without the explicit agreement and the
CA either returns a new cert (for some period of time) or it doesn't.
(We'd want the RFC to be explicit about that possibility if so though)

Either way, this is just one of several ways that automated renewal
could fail - and with the short certificate expiry times that are
currently being suggested that means an admin _always_ needs to be
available on short notice to fix whatever is necessary.

If ToS changes are frequent, and painful to review, then chances are
you'd be wanting to look for a new CA -- no differently to if their
autorenewal failed several times a year because their system was
uncontactable for any other reason.

> an "agreementRequired" error code that the server can use to explicitly

Is there a good reason to ever want the URL to change if the document
itself does not?

The 'easy' answer would seem to be it should only change if the terms
actually change, and it is up to the CA as to whether it will continue
to accept requests under the old terms (for some period of its choosing)
or refuse to accept any new request until the new terms have been
accepted by a human who read and agreed to them.

That gives the CA flexibility depending on how critical it is to them
that the old terms should cease to apply.

If the software is just 'blindly' accepting or updating the terms
with no user interaction, that probably puts a big question mark
over the enforceability of any change to them.

"I didn't agree to that, some software I downloaded off the internet
did that without telling me!"

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 9 Aug 2016 12:11:41 -0700

> everything can be fully automated all of the time.  Sometimes CAs need
> for the tools to get a human in the loop for an updated agreement.
I agree not everything can be automated all the time. That's why I think
that ACME shouldn't try to provide tools for every possible case of ToS
agreements and updates. Here's what I'm thinking:

You are provided with a ToS URL on signup, and agree to it or you're not
able to create an account.
 - If the CA uses legal auto-update language (most common case by far),
nothing else is required.
 - If the CA requires human acceptance of an updated ToS, there's no way
that ACME can automate that. The server will start returning errors with
a link to a page the user can visit to accept a new ToS.

> semantic should be expressed in the protocol.  A CA can always just
> refuse to take any action until a subscriber agrees to the new terms.
Yep, exactly.

---

From: Ron <[email-masked]>
Date: Wed, 10 Aug 2016 05:12:29 +0930

> nothing else is required.

I think in this case we should specify that the CA MUST notify the user
of this via the ACME protocol (ie. by changing the ToS URL or similar).

It doesn't need to automatically result in a failure at the client, but
the client must be able to inform the responsible admin that this has
occurred, so that they can review the new terms.

(which probably means we need a way to signal that they are explicitly
*not* accepted - though that could just be revoking the registration
before the new terms would automatically take effect)

> a link to a page the user can visit to accept a new ToS.

I'd prefer to still see this done via the client software and ACME
(ie. such as passing an --accept-tos flag to the client using the same
process as initial signup to register acceptance with the CA).

As opposed to having to visit some page from an error link and take
some action out of band.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 9 Aug 2016 12:50:53 -0700

> of this via the ACME protocol (ie. by changing the ToS URL or similar).

I'm fine with saying that the directory's terms-of-service URL should
always be up-to-date with the latest ToS, *if* the CA is using ACME for
ToS agreement.

I suspect for most paid CAs, ToS agreement will already have been
handled out-of-band, for instance when submitting payment information.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 9 Aug 2016 13:11:22 -0700

I have a PR up for this: https://github.com/ietf-wg-acme/acme/pull/167

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 16 Aug 2016 18:25:26 -0700

Any further objections to this?

https://github.com/ietf-wg-acme/acme/pull/167/files

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Aug 2016 18:38:05 -0700

Hmm...

  If the server provides a terms-of-service URL in the directory, the
  client MUST indicate its operator's agreement to the terms at that URL
  by including the "terms-of-service": "agreed" field in the
  new-registration body.

This text seems like an attempt to triangulate between what's the
protocol and some notion of user consent (which wasn't really present
in the original version). If I were to implement this code, I might
well just do:

  if (tos_url) {
    msg['terms-of-service'] = 'agreed';
  }

This "indicates" the operator's agreement, I suppose, but it doesn't
actually reflect having obtained it. If the semantic you want is
"client MUST ask the user" then the text should say that, but it seems
like a sensible client would probably just ask the user "shall I
always answer yes to this" at install time, so it's not clear to me
what is being bought here. In any case, this text seems like it makes
things less clear.

-Ekr

---

From: Ron <[email-masked]>
Date: Wed, 17 Aug 2016 17:03:47 +0930

> https://github.com/ietf-wg-acme/acme/pull/167/files

Aside from Eric's remarks, I'm also not too keen on a blanket
"terms-of-service": "agreed", since there's no indication there
of what you've actually "agreed" to.

I don't think this should be a binary (unary?) switch.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 17 Aug 2016 08:18:14 -0700

> in the original version). If I were to implement this code, I might

Are you talking about "client indicates its agreement" vs "client
indicates its operator's agreement?" I wasn't trying to change the
meaning here, just fixing what looked like a grammar semantics error.

> If the server provides a terms-of-service URL in the directory, the
client MUST
> indicate its agreement to the terms at that URL by including the

Look good now?

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 17 Aug 2016 08:24:01 -0700

> of what you've actually "agreed" to.

The indication is in the directory. Is your worry here about the race
condition that Andrew mentioned? It's very rare for terms of service to
change, and rarer still for them to change in such a way that agreeing
to the old one makes a big difference relative to agreeing to the new
one. Certainly it is not a big enough problem to justify any non-trivial
amount of complexity to the protocol.

Can you give an example of a protocol or a website that has a two-step
terms of service agreement to avoid such race conditions?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Aug 2016 08:45:05 -0700

> > indicate its agreement to the terms at that URL by including the

This still just seems confusing, especially with the MUST.

Without worrying about text, what behavior are you attempting to require the
client to engage in?

-Ekr

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 17 Aug 2016 09:22:21 -0700

> Without worrying about text, what behavior are you attempting to require the

Can you tell me more about what you find confusing? Is it just the MUST?
If so, I'm happy to change it to a SHOULD, with the understanding that
the server is likely to reject such requests.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Aug 2016 10:11:24 -0700

> Can you tell me more about what you find confusing? Is it just the MUST?

The whole text.

> the server is likely to reject such requests.

Again, I'd like to step back from the text a bit. It's not a matter of MUST
versus SHOULD
but about what behavior on the part of the client would be needed to be
compliant. For
instance, can it send this PDU without ever prompting the user for consent.

-Ekr

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 17 Aug 2016 10:18:50 -0700

On 08/17/2016 10:11 AM, Eric Rescorla wrote:
> Again, I'd like to step back from the text a bit. It's not a matter of
> MUST versus SHOULD

Can you propose an alternate text? My intent is not to alter the current
state of things with regards to user consent, but merely to simplify the
protocol. What is the text that, for you, would indicate the exact same
things about user consent as the current draft?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Aug 2016 10:47:00 -0700

> things about user consent as the current draft?

I don't think the current text is very clear, so I think if we're going to
not change
that we should keep the text as-is while we discuss what it ought to say.

-Ekr

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 17 Aug 2016 11:27:31 -0700

On 08/17/2016 10:47 AM, Eric Rescorla wrote:
> I don't think the current text is very clear, so I think if we're going
> to not change

In other words, don't change the protocol part until we have the legal /
UI part nailed down? If so, I'd like to see a proposal on the latter. I
don't have an opinion either way, and I'm not a lawyer.

For reference, here is the relevant section from the BRs:

> The CA SHALL implement a process to ensure that each Subscriber or
Terms of Use Agreement is legally enforceable against the Applicant. In
either case, the Agreement MUST apply to the Certificate to be issued
pursuant to the certificate request. The CA MAY use an electronic or
"click-through" Agreement provided that the CA has determined that such
agreements are legally enforceable. A separate Agreement MAY be used for
each certificate request, or a single Agreement MAY be used to cover
multiple future certificate requests and the resulting Certificates, so
long as each Certificate that the CA issues to the Applicant is clearly
covered by that Subscriber or Terms of Use Agreement.

I'm pretty skeptical that we will come up with meaningful language in an
RFC to meet any particular legal requirements, which is why I favor not
trying to over-specify things here.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Aug 2016 11:57:26 -0700

On Wed, Aug 17, 2016 at 11:27 AM, Jacob Hoffman-Andrews <[email-masked]>
wrote:

> UI part nailed down?

No, I'm talking solely about this sentence.

-Ekr

> If so, I'd like to see a proposal on the latter. I

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 17 Aug 2016 13:51:33 -0700

On 08/17/2016 11:57 AM, Eric Rescorla wrote:
> On Wed, Aug 17, 2016 at 11:27 AM, Jacob Hoffman-Andrews <[email-masked]
> <mailto:[email-masked]>> wrote:
>
Alright, I looked at the diff again and tried another pass of making it
a protocol-only change. How's this?
https://github.com/ietf-wg-acme/acme/pull/167

diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
index fa0850a..558df73 100644
--- a/draft-ietf-acme-acme.md
+++ b/draft-ietf-acme-acme.md
@@ -173,8 +173,7 @@ The first phase of ACME is for the client to
register with the ACME server.  The
 client generates an asymmetric key pair and associates this key pair
with a set
 of contact information by signing the contact information.  The server
 acknowledges the registration by replying with a registration object
echoing the
-client's input.  The server can also provide terms of service at this
stage,
-which the client can present to a human user.
+client's input.
 
 ~~~~~~~~~~
       Client                                                  Server
@@ -183,7 +182,6 @@ which the client can present to a human user.
       Signature                     ------->
 
                                     <-------            Registration
-                                                    Terms of Service
 ~~~~~~~~~~

@@ -894,6 +892,7 @@ Content-Type: application/jose+json
     "url": "https://example.com/acme/new-reg"
   })
   "payload": base64url({
+    "terms-of-service": "agreed",
     "contact": [
       "mailto:[email-masked]",
       "tel:+12025551212"
@@ -924,16 +923,13 @@ registration URI.
 If the server wishes to present the client with terms under which the ACME
 service is to be used, it MUST indicate the URI where such terms can be
accessed
 in a Link header with link relation "terms-of-service".  As noted
above, the
-client may indicate its agreement with these terms by updating its
registration
-to include the "agreement" field, with the terms URI as its value. 
When these
-terms change in a way that requires an agreement update, the server MUST
-use a different URI in the Link header.
+client may indicate its agreement when creating registraion by
including the
+"terms-of-service": "agreed" field.
 
 ~~~~~~~~~~
 HTTP/1.1 201 Created
 Content-Type: application/json
 Location: https://example.com/acme/reg/asdf
-Link: <https://example.com/acme/terms>;rel="terms-of-service"
 Link: <https://example.com/acme/some-directory>;rel="directory"
 
 {

---

From: Ron <[email-masked]>
Date: Fri, 19 Aug 2016 11:48:34 +0930

On Wed, Aug 17, 2016 at 08:24:01AM -0700, Jacob Hoffman-Andrews wrote:
> one.

It's more that I don't see what we gain from replacing the rich
interface of:

 "agreement": "<uri of agreement>"

with:

 "terms-of-service": "yeah sure, whatever man"

while we would lose the ability to have explicit agreement to an explicit
ToS.  You say "most" CA's don't need that, but this change would ignore
the needs of the 'few' who might, and the users who would prefer (or
even have a hard requirement) that the ToS does not change without their
explicit knowledge.

We might be able to trust that LE won't ever make some onerous change
to their ToS 'silently' - but I'm not sure that applies broadly.

> Certainly it is not a big enough problem to justify any non-trivial

There's not really any triviality gap between a simple substitution of
a URI obtained from the directory and a hard-coded string.

Every existing client already implemented the former, so it already has
the more-trivial advantage over making them reimplement something else.

My understanding of your original problem which prompted suggesting
this change is that some clients required an additional command line
option from the user to actually pass the "agreement" field.  So they
fell over when LE changed its ToS.

They could just as easily fix that by having a --yeah-sure-whatever
flag that always updates the "agreement" if it changes during fully
automatic operation, which would have the same effect as this change
but not sacrifice the protocol flexibility just to work around what
is effectively a UI bug.

> terms of service agreement to avoid such race conditions?

Well, the usual idiom there is some hidden notice along the lines of
"by downloading this warning, you agree we now own all your private
information and can sell it and your soul to anyone we please ..."
Which nobody ever reads and no court would ever uphold if it came
to that.

Which if that's what "terms-of-service": "agreed" is supposed to
emulate - the genuinely trivial solution would be to just get rid
of it entirely, and make submitting protocol requests the 'agreement'
to whatever the terms-du-jour may be.

I think if we're going to have an explicit protocol flag, it ought
to actually provide a mechanism to implement an explicit agreement
handshake.  It shouldn't just be some useless hard-coded text that
is only there to pay lip service to a CABF requirement of there
being a 'click through' agreement.

I know most people don't care about this stuff, and click through
EULAs (however ridiculous they might be) without ever reading them.
But clients can still easily implement a --max-ennui mode that
people can use for that without hardcoding it as an assumption into
the ACME protocol itself.

Is there some real protocol problem other than that UI issue which
you were trying to fix with this change?

  Cheers,
  Ron

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 19 Aug 2016 09:58:42 -0700

> It's more that I don't see what we gain from replacing the rich

I'm specifically saying that we should strictly avoid rich interfaces
whenever we don't need them. Complexity is always where brokenness
creeps in.

> even have a hard requirement) that the ToS does not change without their

We shouldn't engineer a more complex solution for some CA that "might"
need it without good evidence that they actually do.

> to their ToS 'silently' - but I'm not sure that applies broadly.

If the problem is a service provider acting in bad faith with regards to
their ToS, that's not a problem we can solve with protocol design.

> fell over when LE changed its ToS.

There were several different failure modes. Any one of them can be
treated as a client coding error, but in total they indicate that the
existing protocol was over-complex and under-specified in this area. One
fix would be to specify more heavily how ToS upgrades should go. A
better fix, IMO, would be to simplify the protocol itself to avoid this
whole class of bugs.

---

From: Ron <[email-masked]>
Date: Sat, 20 Aug 2016 10:02:19 +0930

> whenever we don't need them. Complexity is always where brokenness

Ok, forget the word 'rich' then, because I'm not arguing for needless
complexity here either.  What I'm saying is that if we are going to
provide _an_ interface for this, it should actually *be* an interface.

 "terms-of-service":"agreed" is not an interface.

If the only possible use for it is to include exactly that string,
then it's just useless verbiage, not an interface.

We might as well just say that sending a request which would fail if
you didn't include that string indicates acceptance - because doing
anything else just wouldn't work anyway if acceptance isn't optional.

That's the logical conclusion if pruning dead-wood is the goal here.

> need it without good evidence that they actually do.

Sure, but I'm saying that as a user I _do_ want to declare explicitly
what I am agreeing to.  And if we're talking about WGLC in November,
that doesn't leave a lot of time for most of the extant CAs to tell
us what they do or don't need wrt to this.

> their ToS, that's not a problem we can solve with protocol design.

We might not be able to "solve" it.  All I'm asking for is that we don't
_introduce_ it with a bad protocol design, that implies legally binding
acceptance, to uncertain terms, with an ambiguously general nod and wink.

> better fix, IMO, would be to simplify the protocol itself to avoid this

Could you outline at least a few of them, so we can see the specifics of
what you are worried about repeating?

Because I implemented this, using only common sense, without any statement
from LE about if there'd ever be a ToS change, or how things should happen
if there was - and in practice that wasn't a source of trouble.

I don't think we need to specify how to handle ToS changes in much detail
at all.  The important part is that the local admin can be notified that
the ToS for a CA they use _has_ changed, and that they can explicitly
declare exactly which ToS revision they have agreed to.

And we already have simple protocol mechanisms for that in the existing
draft text.

Everything else is outside of the protocol anyway (ie. how clients
behave when a ToS change is seen, and what CAs insist on when they do
change their ToS).  And there's legitimate scope for both of those to
have quite a wide range of choices which suit different people and
organisations.

I don't think you can solve that by 'simplifying' the protocol, but
I do think that we can make that problem worse by oversimplifying,
and replacing useful information with content-less verbiage, and
making too many assumptions about what people "won't ever want to do".

I'd rather we have a little flexibility here, than have 20 competing
standards emerge because we simplified the protocol overzealously and
fundamentally ruled out too many things too quickly.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sun, 21 Aug 2016 15:57:20 -0700

> That's the logical conclusion if pruning dead-wood is the goal here.

I.e. say "If the directory request includes a terms-of-service, posting
to new-registration indicates acceptance of the terms-of-service?" I
would be fine with that, but would need to check with the Let's Encrypt
lawyer and possibly auditors to ensure that would meet the requirements
of the BRs. Would that be acceptable to you? If so I can begin that work.

> us what they do or don't need wrt to this.

As I've said previously, I don't think we're close to being ready for
WGLC in November.

> acceptance, to uncertain terms, with an ambiguously general nod and wink.

Can you give an example of a successful protocol that explicitly
negotiates a versioned terms-of-service?

---

From: Ron <[email-masked]>
Date: Mon, 22 Aug 2016 12:27:03 +0930

> of the BRs. Would that be acceptable to you? If so I can begin that work.

I don't think we need to actually say that in _this_ document (or that
it would have any legal force if we did, since we can't expect that even
client implementors will have read it, let alone end users) - but I do
think that a CA could quite reasonably and easily do exactly that with
the existing mechanism.

All they'd need to do is put that condition in their ToS document, and
then not require receiving an explicit "agreement": "<X>" before
processing requests by the user to create accounts etc. with that CA.

Creating an account is a pretty explicit way to say you agree to the
conditions of the service you are creating an account with.  People
already do that when they walk through a supermarket's door (ie. you
agree to let them search your bags etc.)

Which is why I think the existing mechanism is already about right.
It allows a CA to implement a relaxed mechanism such as the above,
and also gives them the ability to require a more explicit "I have
read and agree to document X", if that's what their legal regime
requires them to do.

Boulder already allows you to register user accounts without indicating
acceptance of the ToS, it doesn't actually block you technically if you
haven't done that until you request a cert.  (or at least that's what
it did the last time I tested that).

If there is something fundamentally wrong with the existing mechanism
then we should fix that - but that's not the problem I'm seeing from
the discussion so far.  The mechanism itself is ok (and about as simple
as it could reasonably be), but LE just used it more strictly than what
you'd ideally prefer to best meet LE's design goals.

It seems reasonable to allow other CAs to be that strict if they desire
(which they might want if issuing EV certs or so), as long as we don't
require that they all MUST be.

> As I've said previously, I don't think we're close to being ready for

Nod.  Which is part of why I'd like us to _not_ change things that
don't actually need changing - because every time we do that, we
push out the time needed to shake out unintended consequences again.

I've already had to pause work on the client that I was implementing.
I'd implemented what Boulder currently supported and all of draft 02
(even though there was no server I could test much of that with)
but given how much of that work now needs to be discarded or rewritten,
it doesn't make a lot of sense to play whack-a-mole with it until some
of these things are a little more settled and certain again.

The ToS management in that was one of the few things that I _didn't_
have anything to grumble about :)

> negotiates a versioned terms-of-service?

I think there's lots of reasons there isn't (and probably can't be) a
good general answer to this, but I think a mechanism that allows the
service to advertise "This is our current ToS" and allows the client
to respond with "This is the ToS I've agreed to", gives us all the
mechanics we need to implement a broad spectrum of options to suit
both CA and end user policies.

 - Servers can individually decide whether they require an explicit
   ack or not, and whether they require it for the current ToS, or
   will provide some grace period where a previous one is still
   acceptable.

 - Clients can individually decide whether they will automatically
   accept a changed ToS, or prompt the user to ack that manually,
   and what mechanism they will use to notify the user of that if
   it ever happens.

I think the best technical example is probably that of software which
might prompt you when you upgrade it about something like "Our data
format has changed.  We can update your existing data to the new
format, but if you do that, you'll no longer be able to use it with
the older version of the software".  Which in turn might either
prompt you to accept that, or just do it to you automatically.

On the legal side of this, the common idiom is a much blunter
instrument.  Lawyers usually write something along the lines of
"You accept we have the power of gods, and can do anything we
please at our sole discretion to which you have no remedy", and
users usually don't read that or care, because in most cases it
won't be enforced in any way that effects them.

But by putting users in permanent breach of the ToS, that gives the
service provider "I know it when I see it" power over deciding what
to ignore and who to stomp on.  Which means usually all they care
about is closing any loopholes when a court rules their ridiculous
terms are unenforceable.  So they don't care about versions, just
how to imply you already accepted the most recent one.

In the case of ACME, I do think we need to care about the needs of
the end user as much as the legal and CABF requirements of the CA,
which is why I think clients need the ability to (at the ends user's
request), _not_ proceed automatically if doing so would change the
terms that the user (and the information they provided the CA) are
subject to.

In the case of LE, I think it would probably be quite reasonable
for the server to not require an explicit agreement beyond continuing
with account registration, and for the "automate everything for
novice users" client to not halt automatic updates on a change of
ToS.  And if end users want something different to that, they can
use a different client, or perhaps a --warn-on-tos-change option
in the 'official' client if it's authors see the value in that.

I just don't think we can generalise to say all CAs and clients
should behave that way.

  Ron

---

From: Richard Barnes <[email-masked]>
Date: Fri, 26 Aug 2016 14:28:43 -0400

I'd like to try to close the loop on this.  I'm hearing pretty broad
agreement here on a few points:

- We should keep the full URL in the agreement field
- The server can update that URL if it doesn't need re-agreement
- The server should indicate the need for agreement with an error

Based on that, I've put together a PR that does the following:

- Add an "agreementRequired" error type
- Require the server to return that error type and the ToS URL when it
requires (re-)agreement
- Allow the server to update the agreement URL if re-agreement is not
required

https://github.com/ietf-wg-acme/acme/pull/182

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 26 Aug 2016 18:47:54 +0000

> I'd like to try to close the loop on this.  I'm hearing pretty broad agreement here on a few points:

> https://github.com/ietf-wg-acme/acme/pull/182

I agree that is consensus, as expressed in Berlin on on-list.  If you disagree, please post within the next week.

	/r$, co-chair

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 29 Aug 2016 14:36:03 -0400

I disagree strongly on this. I've been on vacation last week, and will
be on vacation through Sep 5, but happy to resume the conversation when
I get back.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 29 Aug 2016 18:37:08 +0000

Okay, then.  We'll see if we can get consensus during early September.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

> -----Original Message-----
> From: Jacob Hoffman-Andrews [mailto:[email-masked]]
> Sent: Monday, August 29, 2016 2:36 PM
> To: Salz, Rich; Richard Barnes
> Cc: [email-masked]
> Subject: Re: [Acme] Terms of service agreement changes
> 
> I disagree strongly on this. I've been on vacation last week, and will be on
> vacation through Sep 5, but happy to resume the conversation when I get
> back.
>