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

[Yoav Nir <[e-mail]>]

> On 12 Nov 2015, at 4:06 AM, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> 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?

Lawyers use PDFs, and often use the cringeworthy practice of scanning type-written or printed pages into a PDF. So I don’t think we can require text/plain. I think it’s fine to require PDF/A, especially because there are a lot of PDF viewers out there and not all of them support the advanced stuff like attachments. Realistically, this would not be enforced. I wouldn’t write my ACME client such that it downloads the PDF and validates that it is valid plaintext or PDF/A.

> 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.

Definitely a good idea to keep the agreement stable at least as long as certificates that were issued under it are still unexpired, probably a few more years. The name in the example does suggest versioning to support just that.

Yoav