Re: [Acme] Terms of service agreement changes

[Ron <[e-mail]>]

On Sun, Aug 07, 2016 at 07:07:35PM -0700, Richard Barnes wrote:
> On Sun, Aug 7, 2016 at 8:34 AM, Hugo Landau <[e-mail]> wrote:
> 
> > On Sat, Aug 06, 2016 at 11:30:25AM -0700, Jacob Hoffman-Andrews wrote:
> > > 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.
> >
> > 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.)
> >
> 
> 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

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.

> 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).

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.


> 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.

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!"