2016-08-08 4:07 GMT+02:00 Richard Barnes <[email protected]>: > > > 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 >
How is this supposed to work with automation? Just break it? I guess most client implementations will just agree with the terms then and see a "I have not been stopped" as further agreement. Regards, Niklas > - 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 > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
