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

Richard Barnes <rlb@ipv.sx> Mon, 28 December 2015 22:19 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D299D1ACD54 for <acme@ietfa.amsl.com>; Mon, 28 Dec 2015 14:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.423
X-Spam-Level: *
X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwS10yhMKMMi for <acme@ietfa.amsl.com>; Mon, 28 Dec 2015 14:19:45 -0800 (PST)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C7D1ACD53 for <acme@ietf.org>; Mon, 28 Dec 2015 14:19:45 -0800 (PST)
Received: by mail-vk0-x233.google.com with SMTP id a188so186022789vkc.0 for <acme@ietf.org>; Mon, 28 Dec 2015 14:19:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4G8DEhXxEKvsx14hxRW7/Mwjqa6H4YoobrdWAal5CI4=; b=RwdcphSWRb7aGWxrF4wB46xZFi/8oBrvsbgDR8Sd456rlEHcWVHuEdhlvnBeRGYrQa hRaUrJtLbS5W0K/kkm8ASXH/KGaqeG/o4gbX5VHwwK22BNJmCUZ3cUW692XkaCoXFvyv +fncDyujBhWMnjBLnxG10Vn5sc4rXS9aj27wuZe7YokxstCiVIIJ3TsrSr/0BiUCj6d0 6KwIsNN9MHkEUxGuGX1lC6Sm5C7fvA8mD674Wqs/WBvVzqySTv6CfFIC4xCPFwJJpxDI e493bmYs1gkp72Nl5zm1wHo5cG6zNjKi+9CWc/M0ApSuYhc9BH16kZJ52Ah9ME+nbFJx /R8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4G8DEhXxEKvsx14hxRW7/Mwjqa6H4YoobrdWAal5CI4=; b=NozO+zImunyhfBfLQMgNgJFHqbfyM945IvzDjXNEYUBbHyFFTPnmKQFLWkb7moU1xF Dcgd+4J2f/IvcYobPKybEixo8urPQlGd0xPFafoORB0mT8xbser89SsVKNVRUR9Ypobg 1XX9OCpXEbGLV6lLqSd06NobjamtdlqpMDZWj0AE3hTH7GiyJfG+mc73ZrZXJMKD3h4t I9qfimMEJCtef2waphR/bQJqtPHaYhMbLJ0z92Fd6MpI7vcEwCwJUuTyTcttemiPNdaW hyJtNlgfFpHQpXgjGJsvT+UxKB9wIKZRk6czJHsh1/FtQ72SnP1br9QHIZvAJNq8bofL 7L3Q==
X-Gm-Message-State: ALoCoQm7WEwFmkEodcj+/fAELuAAHObBX1dTTyLcReGZFRuIoCUoH4JLWb6JskOZc3pA5sUaq4s4iZzqOAvDx2czxC3T2U+6XA==
MIME-Version: 1.0
X-Received: by 10.31.107.138 with SMTP id k10mr33776746vki.27.1451341184433; Mon, 28 Dec 2015 14:19:44 -0800 (PST)
Received: by 10.31.11.81 with HTTP; Mon, 28 Dec 2015 14:19:44 -0800 (PST)
In-Reply-To: <CAPWFDXVp5ybDD1uputJmsc7cDk5L_nTdpiuiNAL3a7pBZ0G7zw@mail.gmail.com>
References: <CAPWFDXWx-STKyM-wUvg78onZyh7vROxXm0_8g2+6n79v9Qc+cQ@mail.gmail.com> <87mvuknf8u.fsf@alice.fifthhorseman.net> <CAPWFDXU9n2LZg9-i2+3ehXw+W-7YU8nDbucxdoHkxFcz2F+thg@mail.gmail.com> <876116op8s.fsf@alice.fifthhorseman.net> <CAPWFDXVp5ybDD1uputJmsc7cDk5L_nTdpiuiNAL3a7pBZ0G7zw@mail.gmail.com>
Date: Mon, 28 Dec 2015 17:19:44 -0500
Message-ID: <CAL02cgTRe_K0unsBb+ndApUnL0Gtkh0Nck6G74xTvi0khMHVWw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Matthew Holt <matthew.holt@gmail.com>
Content-Type: multipart/alternative; boundary="001a11478cb8bf0c0b0527fcb3fd"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/3PyQvHo4FEt0SscfG4Fgui4dVVo>
Cc: "acme@ietf.org" <acme@ietf.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Subject: Re: [Acme] Spec change to allow retrieval of Terms of Service URL
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Dec 2015 22:19:48 -0000

On Mon, Dec 21, 2015 at 6:02 PM, Matthew Holt <matthew.holt@gmail.com>
wrote:
> On Thu, Nov 12, 2015 at 2:57 PM Daniel Kahn Gillmor <dkg@fifthhorseman.net
>
> 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.

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
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>