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

[Daniel Kahn Gillmor <[e-mail]>]

On Fri 2015-11-06 14:03:35 -0500, Matthew Holt wrote:
> I'd like to propose a change that allows clients of the ACME protocol to
> obtain the URL to the CA's current Terms of Service (if any) without
> re-registering or trying to obtain a certificate and getting a failure
> response.
>
> This proposal has two parts: adding an entry to the directory, and adding
> the current ToS URL to response headers.
>
> Section 6.2 explains the directory, and adding an entry to the directory
> seems logical:
>
> {
>   "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",
> *  "agreement-url": "https://example.com/acme/subscriber-agreement-v01.pdf
> <https://example.com/acme/subscriber-agreement-v01.pdf>",*
> }
>
> Additionally, including the current ToS in response headers of a failed
> request will allow clients to show the current terms and re-prompt the user
> immediately, if available. Something like this:
>
> *Agreement-URL: https://example.com/acme/subscriber-agreement-v01.pdf
> <https://example.com/acme/subscriber-agreement-v01.pdf>*
>
> Both of these could be optional (as the CA sees fit), but it makes it
> possible for clients to offer a better user experience.

Doesn't this depend on the nature of the data fetched at the given URL?
I'd hope that any inclusion of some mechanism like this would be tightly
constrained with guidance that makes the data both self-contained and
immutable.  Something like:

 a) all the necessary data to understand the subscriber agreement is
    available from that specific URL, without requiring any additional
    resource fetches, arbitrary code execution, etc.  I shouldn't need
    to pull in external stylesheets or images, to run javascript,
    receive or send cookies, etc. in order to be able to render the
    document to the user.  You've used .pdf in your example above: there
    are now PDFs that violate all these assumptions.  Maybe we could
    limit to text/plain; charset=UTF-8, or (if PDF is needed) to PDF/A
    or some similar archival-quality subset of PDF?

 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.

    --dkg