On Wed, Aug 17, 2016 at 08:24:01AM -0700, Jacob Hoffman-Andrews wrote: > On 08/17/2016 12:33 AM, Ron wrote: > > On Tue, Aug 16, 2016 at 06:25:26PM -0700, Jacob Hoffman-Andrews wrote: > >> Any further objections to this? > >> > >> https://github.com/ietf-wg-acme/acme/pull/167/files > > > > Aside from Eric's remarks, I'm also not too keen on a blanket > > "terms-of-service": "agreed", since there's no indication there > > of what you've actually "agreed" to. > > The indication is in the directory. Is your worry here about the race > condition that Andrew mentioned? It's very rare for terms of service to > change, and rarer still for them to change in such a way that agreeing > to the old one makes a big difference relative to agreeing to the new > one.
It's more that I don't see what we gain from replacing the rich interface of: "agreement": "<uri of agreement>" with: "terms-of-service": "yeah sure, whatever man" while we would lose the ability to have explicit agreement to an explicit ToS. You say "most" CA's don't need that, but this change would ignore the needs of the 'few' who might, and the users who would prefer (or even have a hard requirement) that the ToS does not change without their explicit knowledge. We might be able to trust that LE won't ever make some onerous change to their ToS 'silently' - but I'm not sure that applies broadly. > Certainly it is not a big enough problem to justify any non-trivial > amount of complexity to the protocol. There's not really any triviality gap between a simple substitution of a URI obtained from the directory and a hard-coded string. Every existing client already implemented the former, so it already has the more-trivial advantage over making them reimplement something else. My understanding of your original problem which prompted suggesting this change is that some clients required an additional command line option from the user to actually pass the "agreement" field. So they fell over when LE changed its ToS. They could just as easily fix that by having a --yeah-sure-whatever flag that always updates the "agreement" if it changes during fully automatic operation, which would have the same effect as this change but not sacrifice the protocol flexibility just to work around what is effectively a UI bug. > Can you give an example of a protocol or a website that has a two-step > terms of service agreement to avoid such race conditions? Well, the usual idiom there is some hidden notice along the lines of "by downloading this warning, you agree we now own all your private information and can sell it and your soul to anyone we please ..." Which nobody ever reads and no court would ever uphold if it came to that. Which if that's what "terms-of-service": "agreed" is supposed to emulate - the genuinely trivial solution would be to just get rid of it entirely, and make submitting protocol requests the 'agreement' to whatever the terms-du-jour may be. I think if we're going to have an explicit protocol flag, it ought to actually provide a mechanism to implement an explicit agreement handshake. It shouldn't just be some useless hard-coded text that is only there to pay lip service to a CABF requirement of there being a 'click through' agreement. I know most people don't care about this stuff, and click through EULAs (however ridiculous they might be) without ever reading them. But clients can still easily implement a --max-ennui mode that people can use for that without hardcoding it as an assumption into the ACME protocol itself. Is there some real protocol problem other than that UI issue which you were trying to fix with this change? Cheers, Ron _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
