On Sun, Aug 21, 2016 at 03:57:20PM -0700, Jacob Hoffman-Andrews wrote: > On 08/19/2016 05:32 PM, Ron wrote: > > If the only possible use for it is to include exactly that string, > > then it's just useless verbiage, not an interface. > > > > We might as well just say that sending a request which would fail if > > you didn't include that string indicates acceptance - because doing > > anything else just wouldn't work anyway if acceptance isn't optional. > > > > That's the logical conclusion if pruning dead-wood is the goal here. > > I.e. say "If the directory request includes a terms-of-service, posting > to new-registration indicates acceptance of the terms-of-service?" I > would be fine with that, but would need to check with the Let's Encrypt > lawyer and possibly auditors to ensure that would meet the requirements > of the BRs. Would that be acceptable to you? If so I can begin that work.
I don't think we need to actually say that in _this_ document (or that it would have any legal force if we did, since we can't expect that even client implementors will have read it, let alone end users) - but I do think that a CA could quite reasonably and easily do exactly that with the existing mechanism. All they'd need to do is put that condition in their ToS document, and then not require receiving an explicit "agreement": "<X>" before processing requests by the user to create accounts etc. with that CA. Creating an account is a pretty explicit way to say you agree to the conditions of the service you are creating an account with. People already do that when they walk through a supermarket's door (ie. you agree to let them search your bags etc.) Which is why I think the existing mechanism is already about right. It allows a CA to implement a relaxed mechanism such as the above, and also gives them the ability to require a more explicit "I have read and agree to document X", if that's what their legal regime requires them to do. Boulder already allows you to register user accounts without indicating acceptance of the ToS, it doesn't actually block you technically if you haven't done that until you request a cert. (or at least that's what it did the last time I tested that). If there is something fundamentally wrong with the existing mechanism then we should fix that - but that's not the problem I'm seeing from the discussion so far. The mechanism itself is ok (and about as simple as it could reasonably be), but LE just used it more strictly than what you'd ideally prefer to best meet LE's design goals. It seems reasonable to allow other CAs to be that strict if they desire (which they might want if issuing EV certs or so), as long as we don't require that they all MUST be. > > Sure, but I'm saying that as a user I _do_ want to declare explicitly > > what I am agreeing to. And if we're talking about WGLC in November, > > that doesn't leave a lot of time for most of the extant CAs to tell > > us what they do or don't need wrt to this. > > As I've said previously, I don't think we're close to being ready for > WGLC in November. Nod. Which is part of why I'd like us to _not_ change things that don't actually need changing - because every time we do that, we push out the time needed to shake out unintended consequences again. I've already had to pause work on the client that I was implementing. I'd implemented what Boulder currently supported and all of draft 02 (even though there was no server I could test much of that with) but given how much of that work now needs to be discarded or rewritten, it doesn't make a lot of sense to play whack-a-mole with it until some of these things are a little more settled and certain again. The ToS management in that was one of the few things that I _didn't_ have anything to grumble about :) > > We might not be able to "solve" it. All I'm asking for is that we don't > > _introduce_ it with a bad protocol design, that implies legally binding > > acceptance, to uncertain terms, with an ambiguously general nod and wink. > > Can you give an example of a successful protocol that explicitly > negotiates a versioned terms-of-service? I think there's lots of reasons there isn't (and probably can't be) a good general answer to this, but I think a mechanism that allows the service to advertise "This is our current ToS" and allows the client to respond with "This is the ToS I've agreed to", gives us all the mechanics we need to implement a broad spectrum of options to suit both CA and end user policies. - Servers can individually decide whether they require an explicit ack or not, and whether they require it for the current ToS, or will provide some grace period where a previous one is still acceptable. - Clients can individually decide whether they will automatically accept a changed ToS, or prompt the user to ack that manually, and what mechanism they will use to notify the user of that if it ever happens. I think the best technical example is probably that of software which might prompt you when you upgrade it about something like "Our data format has changed. We can update your existing data to the new format, but if you do that, you'll no longer be able to use it with the older version of the software". Which in turn might either prompt you to accept that, or just do it to you automatically. On the legal side of this, the common idiom is a much blunter instrument. Lawyers usually write something along the lines of "You accept we have the power of gods, and can do anything we please at our sole discretion to which you have no remedy", and users usually don't read that or care, because in most cases it won't be enforced in any way that effects them. But by putting users in permanent breach of the ToS, that gives the service provider "I know it when I see it" power over deciding what to ignore and who to stomp on. Which means usually all they care about is closing any loopholes when a court rules their ridiculous terms are unenforceable. So they don't care about versions, just how to imply you already accepted the most recent one. In the case of ACME, I do think we need to care about the needs of the end user as much as the legal and CABF requirements of the CA, which is why I think clients need the ability to (at the ends user's request), _not_ proceed automatically if doing so would change the terms that the user (and the information they provided the CA) are subject to. In the case of LE, I think it would probably be quite reasonable for the server to not require an explicit agreement beyond continuing with account registration, and for the "automate everything for novice users" client to not halt automatic updates on a change of ToS. And if end users want something different to that, they can use a different client, or perhaps a --warn-on-tos-change option in the 'official' client if it's authors see the value in that. I just don't think we can generalise to say all CAs and clients should behave that way. Ron _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
