On Mon, Dec 21, 2015 at 6:02 PM, Matthew Holt <[email protected]>
wrote:
> On Thu, Nov 12, 2015 at 2:57 PM Daniel Kahn Gillmor <[email protected]
>
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
