On Mon, Sep 19, 2016 at 03:43:14PM +0000, Jeremy Rowley wrote:
> For the record, the CAB Forum doesn't police anything and thus can't "turn a
> blind eye" to any action. Whether a CA fulfills a give requirement is in the
> discretion of the browser implementing the CAB Forum BRs, the auditor
> providing the attestation of compliance and the CA.

Sorry.  What I really meant there was a more general "people" rather
than a j'accuse "they".  It really is a hard problem if you remove
"I know it when I see it" as an overriding principle.

> That said, I think there are many CAs interested in complying with both the
> spirit and letter of the CAB Forum requirements while also using ACME.
> Therefore, if ACME truly is CA agnostic, an automated ToS presentation
> should permit a meaningful, binding experience.

That is exactly the assumption I'm interested in from the protocol design
standpoint though.

The key question for me is whether "you registered an account and used
the service, ergo you accept the ToS we presented, in a binding way" can
comply with the accepted spirit and letter of those requirements.

Certainly a lot of lawyers for other network services consider them
binding.  And if they aren't there's a whole lot of ToS documents out
there which have no force at all.


If that holds, it would let us simplify the protocol notably, and
possibly puts the acceptance into more well trodden legal territory
than if we invent something novel for that for ACME.



> -----Original Message-----
> From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Ron
> Sent: Saturday, September 17, 2016 3:08 AM
> To: Jacob Hoffman-Andrews <j...@eff.org>
> Cc: acme@ietf.org
> Subject: Re: [Acme] Simplifying ToS agreement
> 
> On Fri, Sep 16, 2016 at 05:19:55PM -0700, Jacob Hoffman-Andrews wrote:
> > On 09/14/2016 01:14 AM, Ron wrote:
> > > doing some sort of legal theatre lite where the client blindly sends
> > 
> > For better or for worse, there is some "legal theatre lite" required 
> > to get a certificate in the Web PKI. The Baseline Requirements require it.
> > The question is: Do we automate it or do we not automate it?
> 
> And if the answer to that is "we do automate it", then the important
> question is: Does this even remotely satisfy the actual requirement?
> 
> AIUI the CABF requirement is for an explicit agreement that is legally
> binding to the end user in the applicable jurisdiction.
> 
> The problem you ran into with the existing system is that some (many?
> all?) extant clients simply hardcoded:
> 
>  
> "agreement":"https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf
> "
> 
> into their source, without even looking at what the directory reported.
> And that others required user intervention before performing the actions to
> accept a changed ToS URL.
> 
> And the solution you are proposing to 'fix' that is for them to instead
> hardcode "agreement":"yes", so that it still 'works' no matter what random
> text is indicated in the directory at any point in time - and so that doing
> it once implicitly agrees to any future ToS in advance.
> 
> Which is roughly equivalent to adding a line to my client software that
> sends "btw":"You now agree to pay Ron One Beelion dollars tomorrow".
> 
> When the client blindly includes that in a protocol message without the end
> user ever having seen it, you won't have to be a bookkeeper or lawyer to
> correctly guess the chance of any court anywhere considering either of those
> to form a binding contract.
> 
> 
> Will it satisfy the CABF?  Who knows, they turn a blind eye to all sorts of
> things that are inconvenient - but in terms of protocol design, it's not any
> sort of mechanism that provides people options for meeting the requirement,
> or for indicating what you are agreeing to.  It just says you're generically
> agreeable to anything.  And doesn't give you a way to post-facto query what
> it was that some employee of yours actually agreed to on your company's
> behalf, possibly without your knowledge or consent or permission or
> authorisation.
> 
> 
> I would like to see a good way to fix the problem(s) you ran into in
> practice when LE changed its ToS.  What I don't want to see is that we try
> to fix what was a relatively simple client implementation bug by using the
> protocol to mandate people implement something which is fatally flawed and
> unfit for purpose from the outset - because it will be harder and uglier to
> fix that later than if we just punted on this and did nothing at all.
> 
> 
> > > a hard coded "sure, whatever you say, whenever you say it" flag.
> > 
> > I am *not* proposing a "sure, whatever you say, whenever you say it"
> > flag. I am proposing that ACME only needs to know how to agree on 
> > terms of service when creating an account. If the server later wants 
> > their users to agree to new terms, that can be readily be implemented 
> > with error codes and out-of-band URLs.
> > 
> > You are proposing that ACME specify not only initial agreement, but 
> > also how to negotiate subsequent agreements. There is no need for 
> > this, specifically because those subsequent agreements cannot be
> automated.
> > ACME is the Automated Certificate Management Environment. Why would we 
> > include extra plumbing that can only be used manually?
> 
> I don't see how it could possibly be worse to have _one_ well specified
> mechanism which is suitable for _both_ initial agreement and later
> re-agreement if a CA decides that is necessary, that can be implemented
> _once_ in the same client and server software?
> 
> One or both of us seems to be missing something in what the other is saying
> or thinking here ...  since we seem to be in violent agreement about the
> goal, but not about what might actually achieve it.
> 
> If the protocol was to remain as it presently is, where the server declared
> the applicable ToS in the directory, and the client responds with the
> explicit URL of what they have agreed to (and that becomes state in the
> registration object) - then whether or not a change in the ToS can be fully
> automated is *entirely* the decision of of the client side.
> 
> Which IMO is as it should be.  The end user should be the one to decide
> whether a 'blind' change to the ToS is acceptable to them or not, not the
> service provider.
> 
> And all the client software needs to do to provide that choice is to give
> the end user a configuration option that indicates whether or not to
> automatically register acceptance if the ToS ever does change, using the
> same protocol mechanism they used the first time.
> 
> 
> Having already implemented this myself, I know that it works and that it's
> possible :)
> 
> What you are suggesting is that I'd have to replace that with some entirely
> unknown, and unspecified, and possibly different process for every server
> that ever needed this.  So unless I'm missing some key part of what you are
> saying, _that_ is the option which would in fact be entirely impossible to
> automate.
> 
> 
> 
> > > We could just provide a directory entry (which could even be 
> > > optional) that indicates where the terms can be found
> > 
> > This exists, and is what my proposal is based on.
> 
> Sorry, maybe I wasn't clear there - I meant *only* provide the directory
> entry, as a convenience to client software, so the user doesn't have to hunt
> for it at some out of band location.  And make acceptance implicit on
> proceeding with registration.
> 
> Which would have about as much legal weight as including a hidden "I accept"
> constant in the protocol - would delete useless code like you were
> advocating - and has a lot more precedent in existing practice advocated by
> the lawyers of network service providers.
> 
> If that gets ruled invalid in a court, then a lot more than the CABF
> contracts will fall down in a screaming heap.
> 
> 
> > > that any other use of the service indicates acceptance of those 
> > > terms (just like pretty much every other network service in 
> > > existence does without needing to kludge a contentless 'accept' bit into
> the protocol).
> > 
> > I understand this proposal is an unappealing compromise. I feel the 
> > same way. I'd prefer to go all the way and remove explicit agreement 
> > to terms. Unfortunately, the BRs don't seem compatible with this.
> 
> And I understand (and sympathise with) the barrel you are over with this.
> I realise you are looking for the simplest and most foolproof thing that
> will satisfy the CABF BRs - but I'm having a hard time seeing how this would
> even roughly achieve either of the technical or legal aims.
> 
> We'd still have useless cruft that people need to implement, in possibly
> buggy ways, and it would have even less legal standing than what we
> currently have for the purpose of meeting the BRs.
> 
> It's the sort of compromise that has us trying to share a cocktail umbrella
> to keep us out of the rain.  It ties up one hand without actually keeping
> anyone any drier, while I think we do have other viable options here.
> 
> 
> > In another thread, Rich has asked if we are close to consensus. How 
> > strong are your objections? Are you willing to join the CA/Browser 
> > Forum as an Interested Party and propose the necessary change to the BRs?
> 
> I certainly don't want to be a curmudgeon standing in the way of reaching a
> consensus here, and the only thing I really object to with passion is "do
> something half-assed" - I could be just as happy with either of "provide a
> real mechanism" or "excise this from the ACME protocol entirely".  You said
> you'd talk to your legal folk about whether they thought removing it was an
> option, and I don't yet know for sure what the result of that was, which is
> why I hadn't been pushing for one of those options over the other yet and
> wanted to wait until we had more feedback again from you.
> 
> If proceeding with registration on its own constitutes explicit acceptance
> regardless of the content of the protocol message which does that, then I'd
> probably tip toward removing it.  If that's somehow not enough, then I think
> we do need a real mechanism in the protocol that has some chance of being
> flexible enough to work across not only a range of legal jurisdictions and
> desired use cases - but might also survive a change in interpretation of the
> CABF too.
> 
> Even if you and I were to lobby the CABF for a change to their BRs, or were
> to agree that we think an extra magic constant in the protocol really would
> add any legal weight to satisfying them as they are today - the opposite
> could also happen, that enough of the CABF concludes that LE is an
> existential threat to them and so tightens their rules in the other
> direction.  Or a court actually rules that "no way is this sort of thing
> even remotely binding".
> 
> 
> Which is why I think that for making decisions about the protocol, we need
> to think less about "what is the absolute minimum we can get away with for
> the current BRs" - and more about "do we actually need a mechanism for this
> at all or not?".
> 
> If we do need it, it should be a real mechanism for maintaining this as
> shared state between client and server.  If we don't, we should get rid of
> it so that we do have a clean slate to add a proper mechanism later if it
> ever does become needed and what is needed becomes clearer.
> 
> The worst option I see is that we clutter the protocol now with a
> lip-service policy decision that becomes a legacy wart stuck on the side of
> whatever is actually needed to really solve this problem.
> 
> 
> I have a really hard time seeing how the magic constant string that you
> proposed adding would have any more legal weight than just saying in the RFC
> that "a protocol message with a curly brace in it indicates acceptance of
> the terms of service".
> 
> I understand what you are _trying_ to do with that, but I think a lot of
> people would have to pretend pretty hard for it to have any substantial
> difference from the "do nothing" option beyond being an additional
> (re)implementation burden.
> 
> If we can get past that somehow, we should be able to converge on agreement
> about all this pretty quickly.
> 
>   Best,
>   Ron
> 
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to