Two comments: Echoing an etag would be easier. SHA-512 is overkill. On 9 December 2015 at 10:15, Michael Tandy <iaect...@mjt.me.uk> wrote: > 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 > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
