On Mon, Aug 8, 2016 at 3:25 AM, Niklas Keller <[email protected]> wrote:
> 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. > For better or worse, the state of the industry right now is that not everything can be fully automated all of the time. Sometimes CAs need for the tools to get a human in the loop for an updated agreement. Given that that's the state, the only question here is whether this semantic should be expressed in the protocol. A CA can always just refuse to take any action until a subscriber agrees to the new terms. This proposal would just let it happen cleanly, with the client being aware of what the issue is. --Richard > > 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
