> On 12 Nov 2015, at 4:06 AM, Daniel Kahn Gillmor <[email protected]> > 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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
