Currently in the new-reg stage, the client POSTs a signed message, which may contain the URI of a user agreement. If the content of the URL changes, the results could be confusing - client software updating certificates might post the agreement URL without the user having agreed to the revised terms.
Is it worth adding an optional agreement integrity field? We could use a format like this:- "agreement": " https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf";, "agreement-integrity": "sha512-3Ys8QL9di54ggXIGBAS2RHr_W6cMurZPizhZihkQjwl3VG2dpXZYmsYZ0B7LG-tWlVE9-Hwp9hL3Mosvbr6lCA" where the checksum is calculated like so:- $ cat LE-SA-v1.0.1-July-27-2015.pdf | openssl dgst -sha512 -binary | openssl base64 -A | tr -- '+/' '-_' | tr -d '=' 3Ys8QL9di54ggXIGBAS2RHr_W6cMurZPizhZihkQjwl3VG2dpXZYmsYZ0B7LG-tWlVE9-Hwp9hL3Mosvbr6lCA That way if the CA updates the agreement without updating the URL, it'll be clear which version the user has agreed to. The main downsides to this are: 1. It complicates setting up the client; realistically, instead of downloading, reading, and checksumming the user agreement most users will simply copy-and-paste the configuration data from some website. Why add to the boilerplate configuration, making the software harder to use for no real benefit? We all know in reality enforcement of the user agreement will be by certificate revocation, not by the courts; why add to the sound and fury of threatening legalese when it signifies nothing? 2. Perhaps allowing CAs to update their user agreements without the user's knowledge is preferable to CAs breaking users' certificate renewal scripts without the user's knowledge. The latter could mean that a server that is running fine and securely one day will become inaccessible the next day, unable to renew its certificate without manual intervention to accept a new agreement. Reliably sending e-mail is difficult due to spam filtering, so many servers aren't set up to push notification to administrators when problems like this arise. 3. The checksummed agreement could refer to other documents; those would not be covered by the checksum, so they could be changed. The only thing preventing this is good faith on the part of the CAs. Given that we rely on that, why not also rely on the good faith of the CA to update the URL when they update the agreement? 4. If SHA-512 becomes obsolete, manual intervention may be required to calculate a new checksum using an updated algorithm. In the event there were multiple CAs and SHA-512 approached obsolescence, some CAs might only accept SHA-512 while others didn't accept SHA-512. Clients might be complicated with an ability to send multiple checksums, or to negotiate the checksum algorithm. 5. This proposal is similar to http://www.w3.org/TR/SRI/ except this proposal uses URL- and filename-safe base64 encoding (RFC4648 Section 5 with padding removed), only requires SHA-512, and doesn't explicitly support multiple hash algorithms; whereas the SRI recommendation uses traditional base64 encoding (RFC4648 Section 4); requires SHA-256, SHA-384 and SHA-512; and explicitly includes support for multiple hash algorithms. Designs so similar yet incompatible may be a recipe for confusion; perhaps additional differences should be introduced so the incompatible standards are more obviously different. 6. People are already writing client software; maybe it's too late to update the spec for such a marginal improvement. What do you think?
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
