OK, let me clarify my invariants here: I think we can't get away with not supporting the case where the CA updates the terms and needs clients to re-agree. I also feel like the current proposal in #167 is semantically incomplete, like just saying "I agree" ... to what?
I think both of these issues can be addressed with a few tweaks to this Jacob's proposal: - Clarify that having the agreement flag set means that the client has agreed to whatever is in directory["terms-of-service"] - Note that that implies that if the CA changes the terms in a breaking way, then it needs to clear the flag in the registrations - Add an error code "agreementRequired" (as in #182) so that the CA can tell the client when this has happened I agree that this will still be a seldom-exercised code path -- a lazy implementer might still fail to properly handle the "agreementRequired" error code. But at least (1) it gives a conscientious implementer a clear signal and (2) if the client does screw it up and complains to the CA, it gives the CA something they can point to and say "you didn't do this properly". Jacob, can you live with those tweaks? Happy to land #167 and write text for the above in a follow-on PR if folks are agreeable to the approach. --Richard On Sat, Sep 10, 2016 at 7:04 PM, Josh Aas <[email protected]> wrote: > I just want to add that when Jacob says "this is a field that is > updated very rarely and therefore is likely to break poorly > implemented clients if it changes," he is not talking about > theoretical breakage. When we updated the Let's Encrypt subscriber > agreement for the first time some clients broke. > > On Thu, Sep 8, 2016 at 1:40 PM, Jacob Hoffman-Andrews <[email protected]> > wrote: > > Restarting the conversation on > > https://github.com/ietf-wg-acme/acme/pull/167. > > > > An earlier version of the ACME protocol treated the new-reg URL as the > > entry point for all interactions. You'd configure a client with the > > new-reg URL, and after creating an account, you'd get URLs for other > > resources using a series of Link headers. > > > > This posed a problem: How do we integrate a terms-of-service URL? Our > > first approach to this problem was that you get the terms-of-service URL > > *after* you register, via a Link header from your registration object. > > You then POST to the registration with an update. This helped reduce the > > number of URLs and Link headers for clients and servers would have to be > > kept track of, but it was awkward. Ideally users should agree as part of > > the act of registration. Allowing accounts to be in a state where they > > haven't yet agreed to the ToS means more code for both the server and > > the client. > > > > Eventually we switched to using the directory URL as the entry point. > > This solved a number of other problems with URL discovery. This also > > allowed us to present the terms-of-service URL to unauthenticated users, > > and made it possible to agree to the terms during account creation > > rather than afterwards. > > > > Should we continue to model terms-of-service agreement as an updateable > > field on the registration object? Emphatically no. This is not a field > > that users can update, nor is it a field that we expect the server to > > update frequently. In the spirit of AGL's "have one joint and keep it > > well oiled" (https://www.imperialviolet.org/2016/05/16/agility.html), > > this is a field that is updated very rarely and therefore is likely to > > break poorly implemented clients if it changes. It's also redundant with > > the terms-of-service URL that now exists in the directory. The > > "agreement" field in the registration object is an accident of ACME's > > history, and we should fix it before finalizing the protocol. > > > > _______________________________________________ > > Acme mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme > > > > -- > Josh Aas > Executive Director > Internet Security Research Group > Let's Encrypt: A Free, Automated, and Open CA > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
