On Sun, Aug 7, 2016 at 8:34 AM, Hugo Landau <[email protected]> wrote:
> On Sat, Aug 06, 2016 at 11:30:25AM -0700, Jacob Hoffman-Andrews wrote: > > Let's Encrypt recently did its first update of its Subscriber Agreement, > > and ran into some incompatibility. The current spec makes it seem like > > the client should update the registration object whenever the Subscriber > > Agreement (known in ACME as terms-of-service) changes. > > > > However, early in drafting LE's Subscriber Agreement, we realized that > > if we required human approval of Subscriber Agreement changes, that > > would break auto-renewal. So our Subscriber Agreement says that updates > > automatically apply to existing users after a notice period.* > > > > The existing ACME terms-of-service flow is an awkward hold-over from > > when we treated the new-reg URL as the entry point. Currently you create > > an account, get told the ToS URL, and update the account object with > > that URL. That then gets stored as a property of the registration object > > forever. > > > > Now that we have the directory object, and it contains a > > terms-of-service URL, we can say that for CAs with a terms-of-service > > URL, you must agree before you can create an account. We can have an > > "agree": true field in the new-reg POST to signal agreement to the > > current terms-of-service from the directory object. Then the > > terms-of-service URL doesn't need to be a permanent part of the > > registration object, and we can avoid ambiguity over whether and when > > clients need to update or check it. > > I don't think we need to get rid of the URI-based approach. Though this > is rather asinine, '"agree": true' would be vulnerable to race > conditions between retrieving the directory and registering (...). > > Here are some more options: > > 1. Add a "agreement-valid": bool field to the registration object > which indicates whether the current agreement value is valid even > if it doesn't match the ToS valid. > > 2. Have the server return a ToS link value equalling the old (but still > acceptable) agreement value when returning registration data. > Registrations with a no-longer-acceptable agreement value or > no agreement set get the current ToS link value. > > 3. Update the agreement URI for all accounts when updating agreements, > so that the agreement URI always matches the Link-advertised URI > if the agreement is valid. Not really feasible if there's a notice > period, though, assuming the notice period doesn't apply to new > registrations. > > I think option 1 is probably the best, but I may be biased in favour of > what's easiest to implement in my own client. > > (In the LE case specifically, I wonder if the URI needs to change at all > if the agreement is designed so that updates apply automatically. Each > version should probably have an immutable archival URI, but a single > fixed URI could point to the current version. Still, this needs to be > worked out in the spec.) > I agree with Hugo that it seems like there's still value in having the URI in the registration object. It seems like there's probably requirements on both sides here: - The CA needs to be able prompt re-agreement - The CA needs to be able to update the terms/SA URL without prompting re-agreement We can meet both of these if, as Hugo notes, we let the CA update the agreement URI in the registration object. Then the client can compare the URI in the object to the URI in the directory / link header, and if they differ, prompt for re-agreement (or deactivate the registration). Spec-wise, I think we would just want to add a note that the server can update the agreement URL in the registration object in cases where agreement with the old implies agreement with the new (e.g., if they represent the same document and just the URL changed). We might also want an "agreementRequired" error code that the server can use to explicitly prompt for re-agreement. --Richard > > Hugo Landau > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
