How about just requiring that CAs update the URL on changes? Let's Encrypt has a phrase in their agreement that further usage = agreement to new terms to ensure that it doesn't break automation.
Martin Thomson <[email protected]> schrieb am Mi., 9. Dez. 2015 02:10: > Two comments: Echoing an etag would be easier. SHA-512 is overkill. > > On 9 December 2015 at 10:15, Michael Tandy <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
