Re: [Acme] Spec change to allow retrieval of Terms of Service URL

[Matthew Holt <[e-mail]>]

On Thu, Nov 12, 2015 at 2:57 PM Daniel Kahn Gillmor <[e-mail]>
wrote:

> On Thu 2015-11-12 10:30:44 -0500, Matthew Holt wrote:
> > If the client leaves it up to the user to follow the link, then the
> format
> > shouldn't matter in terms of the ACME spec; it is up to the document
> > renderer (browser) to do so safely and correctly.
>
> if the spec has any implications that the user is agreeing to something
> by proceeding with the process, then the spec needs to be really clear
> what it means.  If a document is unreadable by a user with (for example)
> a browser that declines to execute javascript, or a browser cannot
> access third-party resources, then the spec is encouraging both parties
> (subscribers and CAs) to lie to each other.
>

Already, the spec has provisions for a link to terms (sec. 6.3) and that's
the extent of it. There's no need for the specification to imply that
_continuing_ the process signifies agreement; the client can take care of
that. And I don't see why the spec can't be agnostic about the Content-Type
it links to; it's between the client, the user, and the server to negotiate
agreements; the spec can merely facilitate the means. How exactly the user
agrees to the terms set by the user is irrelevant to the specification.


>
> > If the client were to actually download and show the document to the
> user,
> > then yes, plain text would be much better. Most terminal-based clients
> will
> > probably not want to show the full legal terms in the terminal window,
> but
> > would prefer a link. Simpler, less screen space required, accomplishes
> same
> > goal.
>
> They don't appear to accomplish the same goal to me.  Maybe we need to
> spell out what the goal is more explicitly?
>

The goal is simply this: If the server requires agreement to terms, there
should be a way to link to the current terms from the directory without
having to perform a transaction that attempts to mutate state. Hope that
makes more sense.


>
> >>  b) That the resource fetched from that URL will never change.  I don't
> >>     want to retrieve the URL at time T, display it to the user, and then
> >>     have the user continue the process at time T+2 when the document
> >>     changed at time T+1.
> >
> > That's the idea. The URL to that version of the document should never
> > change (ideally, but I suppose that is up to the CAs), but if it does, it
> > means there is a new document, i.e. updated terms, the user must agree
> to.
> > So the URL would be assumed to be a key or token value representing the
> > actual legal text; if it changes, the user should be re-prompted.
>
> If the intent is to be able to update the terms of service in
> continuance of the subscriber relationship, then the immutability of the
> provided statement needs to be much more carefully spelled out.
>
> Terms of Service, notice, and consent are complex problems with effects
> going all the way up the stack to layer 9.  If ACME proposes to treat
> them as in-scope for the specification, we need to be careful and
> explicit about how they're being tied in.
>
> I know "the IETF does not do UI", but we need to describe at least the
> semantics of tasks that the UI needs to perform on behalf of the
> subscriber (or, possibly, of the CA) if we expect this additional field
> to be a meaningful part of the protocol.
>

If ACME is to facilitate automation, then it should take into account the
legal barriers. Since certificates are often used with long-running
processes (web and mail servers), the end user may not be physically
present when a transaction takes place. If an ACME server is going to
forbid requests due to agreement error, it would be helpful to know that
before the user goes away.

Hopefully this makes sense; I've run into this problem in developing a
long-running ACME client. But I believe this problem has already been
resolved in another discussion.

What I'm trying to get at is a way of getting the ToS URL "for free"
without having to invoke any other action on the server.

Matt