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

From: Matthew Holt <[email-masked]>
Date: Mon, 21 Dec 2015 23:02:35 +0000

On Thu, Nov 12, 2015 at 2:57 PM Daniel Kahn Gillmor <[email-masked]>
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

---

From: Richard Barnes <[email-masked]>
Date: Mon, 28 Dec 2015 17:19:44 -0500

On Mon, Dec 21, 2015 at 6:02 PM, Matthew Holt <[email-masked]>
wrote:
> On Thu, Nov 12, 2015 at 2:57 PM Daniel Kahn Gillmor <[email-masked]
>
> wrote:
>>
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.
without
> having to invoke any other action on the server.

I see what you're saying here.  Sorry for not getting to this sooner.

I'm sort of tempted to put this in a "meta" field in the directory, since
it's not really an ACME endpoint.  And such a field seems like a handy
place to publish other information about a CA.  For example, you could put
in a link to the CA's website, or define a little format for what CSRs a CA
will accept.

{

*  "meta": {    "terms-of-service":
"https://example.com/acme/subscriber-agreement-v01.pdf
<https://example.com/acme/subscriber-agreement-v01.pdf>",    "website":
"https://www.example.com/ <https://www.example.com/>",  },*
  "new-reg": "https://example.com/acme/new-reg",
  "recover-reg": "https://example.com/acme/recover-reg",
  "new-authz": "https://example.com/acme/new-authz",
  "new-cert": "https://example.com/acme/new-cert",
  "revoke-cert": "https://example.com/acme/revoke-cert",
}

In any case, I filed #59 for this:

https://github.com/ietf-wg-acme/acme/issues/59

--Richard

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

---

From: Richard Barnes <[email-masked]>
Date: Mon, 28 Dec 2015 17:28:35 -0500

> to be a meaningful part of the protocol.

ISTM that what we need to do here is provide tools that will be configured
by layer 9 :)

There are a few basic operations to facilitate:
1. Enable the client to present the TOS to the user
2. Enable the client to indicate the user's agreement with the TOS
3. Enable the client to detect when the TOS changes
4. Enable the server to indicate when the client needs to re-agree

For (1) and (3), having a URI for the terms seems sufficient, without
further constraints.  It's up to the CA to figure out how to present the
terms in a way that clients can handle, and up to clients to figure out how
to handle a reasonable array of stuff.  (I expect in most cases it will get
punted to a browser anyway.)

For (2), we have the "agreement" field in the registration POST.

I think (4) is adequately addressed by the text added in #52 (
https://github.com/ietf-wg-acme/acme/pull/52).

So I'm not seeing a whole lot of need for new mechanism here.

--Richard

>          --dkg

---

From: Matthew Holt <[email-masked]>
Date: Tue, 29 Dec 2015 00:26:52 +0000

That'll work - I like the idea of the meta field. No new operations seem
necessary if that is present.

On Mon, Dec 28, 2015 at 3:28 PM Richard Barnes <[email-masked]> wrote:

> On Thu, Nov 12, 2015 at 4:57 PM, Daniel Kahn Gillmor <
> [email-masked]> wrote:
>