Re: [Acme] Terms of service agreement changes

2016-09-08 Thread Salz, Rich 
Last month we called for consensus on this, and one person asked for more time.

As co-chair, if there are no objections raised, and discussion started, by next 
week, we’ll declare that the WG is in at least rough consensus on this issue.

Please look at 
https://github.com/ietf-wg-acme/acme/pull/182<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_182=DQMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=L1U2k8yIvoeUD7i6XFfqwcpU80klhqxqtLQwTy0hxPQ=a8o_Zi8GaJIZPYq9tbeKeNmMMkAWzrLW8XI8wRjIZaU=>
 for sample text.


--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz

From: Richard Barnes [mailto:r...@ipv.sx]
Sent: Thursday, September 08, 2016 1:06 PM
To: Salz, Rich
Cc: Jacob Hoffman-Andrews; acme@ietf.org
Subject: Re: [Acme] Terms of service agreement changes

So, it's early September... ?

On Mon, Aug 29, 2016 at 2:37 PM, Salz, Rich 
<rs...@akamai.com<mailto:rs...@akamai.com>> wrote:
Okay, then.  We'll see if we can get consensus during early September.


--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at<mailto:richs...@jabber.at> Twitter: RichSalz


> -Original Message-
> From: Jacob Hoffman-Andrews [mailto:j...@eff.org<mailto:j...@eff.org>]
> Sent: Monday, August 29, 2016 2:36 PM
> To: Salz, Rich; Richard Barnes
> Cc: acme@ietf.org<mailto:acme@ietf.org>
> Subject: Re: [Acme] Terms of service agreement changes
>
> I disagree strongly on this. I've been on vacation last week, and will be on
> vacation through Sep 5, but happy to resume the conversation when I get
> back.
>
> On 08/26/2016 02:47 PM, Salz, Rich wrote:
> >> I'd like to try to close the loop on this.  I'm hearing pretty broad
> agreement here on a few points:
> >> - We should keep the full URL in the agreement field
> >> - The server can update that URL if it doesn't need re-agreement
> >> - The server should indicate the need for agreement with an error
> >> https://github.com/ietf-wg-acme/acme/pull/182<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_182=DQMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=L1U2k8yIvoeUD7i6XFfqwcpU80klhqxqtLQwTy0hxPQ=a8o_Zi8GaJIZPYq9tbeKeNmMMkAWzrLW8XI8wRjIZaU=>
> > I agree that is consensus, as expressed in Berlin on on-list.  If you 
> > disagree,
> please post within the next week.
> >
> > /r$, co-chair
> >
> >
> > ___
> > Acme mailing list
> > Acme@ietf.org<mailto:Acme@ietf.org>
> > https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme=DQMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=L1U2k8yIvoeUD7i6XFfqwcpU80klhqxqtLQwTy0hxPQ=8_PrA_iaCGbCTfg6OUAoqpC_1dgZFtfUC91kW7Ljjds=>
>
> ___
> Acme mailing list
> Acme@ietf.org<mailto:Acme@ietf.org>
> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme=DQMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=L1U2k8yIvoeUD7i6XFfqwcpU80klhqxqtLQwTy0hxPQ=8_PrA_iaCGbCTfg6OUAoqpC_1dgZFtfUC91kW7Ljjds=>

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

Re: [Acme] Terms of service agreement changes

2016-09-08 Thread Richard Barnes 
So, it's early September... ?

On Mon, Aug 29, 2016 at 2:37 PM, Salz, Rich <rs...@akamai.com> wrote:

> Okay, then.  We'll see if we can get consensus during early September.
>
>
> --
> Senior Architect, Akamai Technologies
> IM: richs...@jabber.at Twitter: RichSalz
>
>
> > -Original Message-
> > From: Jacob Hoffman-Andrews [mailto:j...@eff.org]
> > Sent: Monday, August 29, 2016 2:36 PM
> > To: Salz, Rich; Richard Barnes
> > Cc: acme@ietf.org
> > Subject: Re: [Acme] Terms of service agreement changes
> >
> > I disagree strongly on this. I've been on vacation last week, and will
> be on
> > vacation through Sep 5, but happy to resume the conversation when I get
> > back.
> >
> > On 08/26/2016 02:47 PM, Salz, Rich wrote:
> > >> I'd like to try to close the loop on this.  I'm hearing pretty broad
> > agreement here on a few points:
> > >> - We should keep the full URL in the agreement field
> > >> - The server can update that URL if it doesn't need re-agreement
> > >> - The server should indicate the need for agreement with an error
> > >> https://github.com/ietf-wg-acme/acme/pull/182
> > > I agree that is consensus, as expressed in Berlin on on-list.  If you
> disagree,
> > please post within the next week.
> > >
> > > /r$, co-chair
> > >
> > >
> > > ___
> > > 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
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Terms of service agreement changes

2016-08-29 Thread Salz, Rich 
Okay, then.  We'll see if we can get consensus during early September.


--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz


> -Original Message-
> From: Jacob Hoffman-Andrews [mailto:j...@eff.org]
> Sent: Monday, August 29, 2016 2:36 PM
> To: Salz, Rich; Richard Barnes
> Cc: acme@ietf.org
> Subject: Re: [Acme] Terms of service agreement changes
> 
> I disagree strongly on this. I've been on vacation last week, and will be on
> vacation through Sep 5, but happy to resume the conversation when I get
> back.
> 
> On 08/26/2016 02:47 PM, Salz, Rich wrote:
> >> I'd like to try to close the loop on this.  I'm hearing pretty broad
> agreement here on a few points:
> >> - We should keep the full URL in the agreement field
> >> - The server can update that URL if it doesn't need re-agreement
> >> - The server should indicate the need for agreement with an error
> >> https://github.com/ietf-wg-acme/acme/pull/182
> > I agree that is consensus, as expressed in Berlin on on-list.  If you 
> > disagree,
> please post within the next week.
> >
> > /r$, co-chair
> >
> >
> > ___
> > 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

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

Re: [Acme] Terms of service agreement changes

2016-08-29 Thread Jacob Hoffman-Andrews 
I disagree strongly on this. I've been on vacation last week, and will
be on vacation through Sep 5, but happy to resume the conversation when
I get back.

On 08/26/2016 02:47 PM, Salz, Rich wrote:
>> I'd like to try to close the loop on this.  I'm hearing pretty broad 
>> agreement here on a few points:
>> - We should keep the full URL in the agreement field
>> - The server can update that URL if it doesn't need re-agreement
>> - The server should indicate the need for agreement with an error
>> https://github.com/ietf-wg-acme/acme/pull/182
> I agree that is consensus, as expressed in Berlin on on-list.  If you 
> disagree, please post within the next week.
>
>   /r$, co-chair
>
>
> ___
> 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

Re: [Acme] Terms of service agreement changes

2016-08-21 Thread Ron 
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": "" 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

Re: [Acme] Terms of service agreement changes

2016-08-21 Thread Jacob Hoffman-Andrews 
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.

> 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.

> 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?

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

Re: [Acme] Terms of service agreement changes

2016-08-19 Thread Ron 
On Fri, Aug 19, 2016 at 09:58:42AM -0700, Jacob Hoffman-Andrews wrote:
> On 08/18/2016 07:18 PM, Ron wrote:
> > It's more that I don't see what we gain from replacing the rich
> > interface of:
> 
> I'm specifically saying that we should strictly avoid rich interfaces
> whenever we don't need them. Complexity is always where brokenness
> creeps in.

Ok, forget the word 'rich' then, because I'm not arguing for needless
complexity here either.  What I'm saying is that if we are going to
provide _an_ interface for this, it should actually *be* an interface.

 "terms-of-service":"agreed" is not an interface.

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.


> > 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 shouldn't engineer a more complex solution for some CA that "might"
> need it without good evidence that they actually do.

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.


> > 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.
> 
> If the problem is a service provider acting in bad faith with regards to
> their ToS, that's not a problem we can solve with protocol design.

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.


> > 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.
> 
> There were several different failure modes. Any one of them can be
> treated as a client coding error, but in total they indicate that the
> existing protocol was over-complex and under-specified in this area. One
> fix would be to specify more heavily how ToS upgrades should go. A
> better fix, IMO, would be to simplify the protocol itself to avoid this
> whole class of bugs.

Could you outline at least a few of them, so we can see the specifics of
what you are worried about repeating?

Because I implemented this, using only common sense, without any statement
from LE about if there'd ever be a ToS change, or how things should happen
if there was - and in practice that wasn't a source of trouble.

I don't think we need to specify how to handle ToS changes in much detail
at all.  The important part is that the local admin can be notified that
the ToS for a CA they use _has_ changed, and that they can explicitly
declare exactly which ToS revision they have agreed to.

And we already have simple protocol mechanisms for that in the existing
draft text.


Everything else is outside of the protocol anyway (ie. how clients
behave when a ToS change is seen, and what CAs insist on when they do
change their ToS).  And there's legitimate scope for both of those to
have quite a wide range of choices which suit different people and
organisations.

I don't think you can solve that by 'simplifying' the protocol, but
I do think that we can make that problem worse by oversimplifying,
and replacing useful information with content-less verbiage, and
making too many assumptions about what people "won't ever want to do".


I'd rather we have a little flexibility here, than have 20 competing
standards emerge because we simplified the protocol overzealously and
fundamentally ruled out too many things too quickly.



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

Re: [Acme] Terms of service agreement changes

2016-08-19 Thread Jacob Hoffman-Andrews 
On 08/18/2016 07:18 PM, Ron wrote:
> It's more that I don't see what we gain from replacing the rich
> interface of:

I'm specifically saying that we should strictly avoid rich interfaces
whenever we don't need them. Complexity is always where brokenness
creeps in.

> 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 shouldn't engineer a more complex solution for some CA that "might"
need it without good evidence that they actually do.

> 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.

If the problem is a service provider acting in bad faith with regards to
their ToS, that's not a problem we can solve with protocol design.

> 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.

There were several different failure modes. Any one of them can be
treated as a client coding error, but in total they indicate that the
existing protocol was over-complex and under-specified in this area. One
fix would be to specify more heavily how ToS upgrades should go. A
better fix, IMO, would be to simplify the protocol itself to avoid this
whole class of bugs.

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

Re: [Acme] Terms of service agreement changes

2016-08-18 Thread Ron 
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": ""

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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Terms of service agreement changes

2016-08-17 Thread Jacob Hoffman-Andrews 
On 08/17/2016 11:57 AM, Eric Rescorla wrote:
> On Wed, Aug 17, 2016 at 11:27 AM, Jacob Hoffman-Andrews  > wrote:
>
> On 08/17/2016 10:47 AM, Eric Rescorla wrote:
> > I don't think the current text is very clear, so I think if
> we're going
> > to not change
> > that we should keep the text as-is while we discuss what it
> ought to say.
>
> In other words, don't change the protocol part until we have the
> legal /
> UI part nailed down?
>
>
> No, I'm talking solely about this sentence.
Alright, I looked at the diff again and tried another pass of making it
a protocol-only change. How's this?
https://github.com/ietf-wg-acme/acme/pull/167

diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
index fa0850a..558df73 100644
--- a/draft-ietf-acme-acme.md
+++ b/draft-ietf-acme-acme.md
@@ -173,8 +173,7 @@ The first phase of ACME is for the client to
register with the ACME server.  The
 client generates an asymmetric key pair and associates this key pair
with a set
 of contact information by signing the contact information.  The server
 acknowledges the registration by replying with a registration object
echoing the
-client's input.  The server can also provide terms of service at this
stage,
-which the client can present to a human user.
+client's input.
 
 ~~
   Client  Server
@@ -183,7 +182,6 @@ which the client can present to a human user.
   Signature --->
 
 <---Registration
-Terms of Service
 ~~
 
 
@@ -894,6 +892,7 @@ Content-Type: application/jose+json
 "url": "https://example.com/acme/new-reg;
   })
   "payload": base64url({
+"terms-of-service": "agreed",
 "contact": [
   "mailto:cert-ad...@example.com;,
   "tel:+12025551212"
@@ -924,16 +923,13 @@ registration URI.
 If the server wishes to present the client with terms under which the ACME
 service is to be used, it MUST indicate the URI where such terms can be
accessed
 in a Link header with link relation "terms-of-service".  As noted
above, the
-client may indicate its agreement with these terms by updating its
registration
-to include the "agreement" field, with the terms URI as its value. 
When these
-terms change in a way that requires an agreement update, the server MUST
-use a different URI in the Link header.
+client may indicate its agreement when creating registraion by
including the
+"terms-of-service": "agreed" field.
 
 ~~
 HTTP/1.1 201 Created
 Content-Type: application/json
 Location: https://example.com/acme/reg/asdf
-Link: ;rel="terms-of-service"
 Link: ;rel="directory"
 
 {

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

Re: [Acme] Terms of service agreement changes

2016-08-17 Thread Jacob Hoffman-Andrews 
On 08/17/2016 10:47 AM, Eric Rescorla wrote:
> I don't think the current text is very clear, so I think if we're going
> to not change
> that we should keep the text as-is while we discuss what it ought to say.

In other words, don't change the protocol part until we have the legal /
UI part nailed down? If so, I'd like to see a proposal on the latter. I
don't have an opinion either way, and I'm not a lawyer.

For reference, here is the relevant section from the BRs:

> The CA SHALL implement a process to ensure that each Subscriber or
Terms of Use Agreement is legally enforceable against the Applicant. In
either case, the Agreement MUST apply to the Certificate to be issued
pursuant to the certificate request. The CA MAY use an electronic or
"click-through" Agreement provided that the CA has determined that such
agreements are legally enforceable. A separate Agreement MAY be used for
each certificate request, or a single Agreement MAY be used to cover
multiple future certificate requests and the resulting Certificates, so
long as each Certificate that the CA issues to the Applicant is clearly
covered by that Subscriber or Terms of Use Agreement.

I'm pretty skeptical that we will come up with meaningful language in an
RFC to meet any particular legal requirements, which is why I favor not
trying to over-specify things here.

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

Re: [Acme] Terms of service agreement changes

2016-08-17 Thread Jacob Hoffman-Andrews 
On 08/17/2016 10:11 AM, Eric Rescorla wrote:
> Can you tell me more about what you find confusing? Is it just the MUST?
> 
> The whole text.
> If so, I'm happy to change it to a SHOULD, with the understanding that
> the server is likely to reject such requests.
> 
> 
> Again, I'd like to step back from the text a bit. It's not a matter of
> MUST versus SHOULD
> but about what behavior on the part of the client would be needed to be
> compliant. For
> instance, can it send this PDU without ever prompting the user for consent.

Can you propose an alternate text? My intent is not to alter the current
state of things with regards to user consent, but merely to simplify the
protocol. What is the text that, for you, would indicate the exact same
things about user consent as the current draft?

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

Re: [Acme] Terms of service agreement changes

2016-08-17 Thread Eric Rescorla 
On Wed, Aug 17, 2016 at 9:22 AM, Jacob Hoffman-Andrews  wrote:

> On 08/17/2016 08:45 AM, Eric Rescorla wrote:
> > This still just seems confusing, especially with the MUST.
> >
> > Without worrying about text, what behavior are you attempting to require
> the
> > client to engage in?
>
> Can you tell me more about what you find confusing? Is it just the MUST?
>

The whole text.



> If so, I'm happy to change it to a SHOULD, with the understanding that
> the server is likely to reject such requests.


Again, I'd like to step back from the text a bit. It's not a matter of MUST
versus SHOULD
but about what behavior on the part of the client would be needed to be
compliant. For
instance, can it send this PDU without ever prompting the user for consent.

-Ekr



___
> 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

Re: [Acme] Terms of service agreement changes

2016-08-17 Thread Eric Rescorla 
On Wed, Aug 17, 2016 at 8:18 AM, Jacob Hoffman-Andrews  wrote:

> On 08/16/2016 06:38 PM, Eric Rescorla wrote:
> > This text seems like an attempt to triangulate between what's the
> > protocol and some notion of user consent (which wasn't really present
> > in the original version). If I were to implement this code, I might
> > well just do:
>
> Are you talking about "client indicates its agreement" vs "client
> indicates its operator's agreement?" I wasn't trying to change the
> meaning here, just fixing what looked like a grammar semantics error.
> But I'm not attached to the fix. I just pushed a change back to:
>
> > If the server provides a terms-of-service URL in the directory, the
> client MUST
> > indicate its agreement to the terms at that URL by including the
>
> Look good now?
>

This still just seems confusing, especially with the MUST.

Without worrying about text, what behavior are you attempting to require the
client to engage in?

-Ekr


> ___
> 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

Re: [Acme] Terms of service agreement changes

2016-08-17 Thread Jacob Hoffman-Andrews 
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. Certainly it is not a big enough problem to justify any non-trivial
amount of complexity to the protocol.

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?

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

Re: [Acme] Terms of service agreement changes

2016-08-17 Thread Jacob Hoffman-Andrews 
On 08/16/2016 06:38 PM, Eric Rescorla wrote:
> This text seems like an attempt to triangulate between what's the
> protocol and some notion of user consent (which wasn't really present
> in the original version). If I were to implement this code, I might
> well just do:

Are you talking about "client indicates its agreement" vs "client
indicates its operator's agreement?" I wasn't trying to change the
meaning here, just fixing what looked like a grammar semantics error.
But I'm not attached to the fix. I just pushed a change back to:

> If the server provides a terms-of-service URL in the directory, the
client MUST
> indicate its agreement to the terms at that URL by including the

Look good now?

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

Re: [Acme] Terms of service agreement changes

2016-08-17 Thread Ron 
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.

I don't think this should be a binary (unary?) switch.


> On 08/09/2016 12:50 PM, Jacob Hoffman-Andrews wrote:
> > On 08/09/2016 12:42 PM, Ron wrote:
> >>>  - If the CA uses legal auto-update language (most common case by far),
> >>> nothing else is required.
> >>
> >> I think in this case we should specify that the CA MUST notify the user
> >> of this via the ACME protocol (ie. by changing the ToS URL or similar).
> > 
> > I'm fine with saying that the directory's terms-of-service URL should
> > always be up-to-date with the latest ToS, *if* the CA is using ACME for
> > ToS agreement.
> > 
> > 
> > I suspect for most paid CAs, ToS agreement will already have been
> > handled out-of-band, for instance when submitting payment information.

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

Re: [Acme] Terms of service agreement changes

2016-08-16 Thread Eric Rescorla 
Hmm...

  If the server provides a terms-of-service URL in the directory, the
  client MUST indicate its operator's agreement to the terms at that URL
  by including the "terms-of-service": "agreed" field in the
  new-registration body.

This text seems like an attempt to triangulate between what's the
protocol and some notion of user consent (which wasn't really present
in the original version). If I were to implement this code, I might
well just do:

  if (tos_url) {
msg['terms-of-service'] = 'agreed';
  }

This "indicates" the operator's agreement, I suppose, but it doesn't
actually reflect having obtained it. If the semantic you want is
"client MUST ask the user" then the text should say that, but it seems
like a sensible client would probably just ask the user "shall I
always answer yes to this" at install time, so it's not clear to me
what is being bought here. In any case, this text seems like it makes
things less clear.

-Ekr



On Tue, Aug 16, 2016 at 6:25 PM, Jacob Hoffman-Andrews  wrote:

> Any further objections to this?
>
> https://github.com/ietf-wg-acme/acme/pull/167/files
>
> On 08/09/2016 12:50 PM, Jacob Hoffman-Andrews wrote:
> > On 08/09/2016 12:42 PM, Ron wrote:
> >>>  - If the CA uses legal auto-update language (most common case by far),
> >>> nothing else is required.
> >>
> >> I think in this case we should specify that the CA MUST notify the user
> >> of this via the ACME protocol (ie. by changing the ToS URL or similar).
> >
> > I'm fine with saying that the directory's terms-of-service URL should
> > always be up-to-date with the latest ToS, *if* the CA is using ACME for
> > ToS agreement.
> >
> >
> > I suspect for most paid CAs, ToS agreement will already have been
> > handled out-of-band, for instance when submitting payment information.
> >
> > ___
> > 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
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Terms of service agreement changes

2016-08-16 Thread Jacob Hoffman-Andrews 
Any further objections to this?

https://github.com/ietf-wg-acme/acme/pull/167/files

On 08/09/2016 12:50 PM, Jacob Hoffman-Andrews wrote:
> On 08/09/2016 12:42 PM, Ron wrote:
>>>  - If the CA uses legal auto-update language (most common case by far),
>>> nothing else is required.
>>
>> I think in this case we should specify that the CA MUST notify the user
>> of this via the ACME protocol (ie. by changing the ToS URL or similar).
> 
> I'm fine with saying that the directory's terms-of-service URL should
> always be up-to-date with the latest ToS, *if* the CA is using ACME for
> ToS agreement.
> 
> 
> I suspect for most paid CAs, ToS agreement will already have been
> handled out-of-band, for instance when submitting payment information.
> 
> ___
> 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

Re: [Acme] Terms of service agreement changes

2016-08-09 Thread Ron 
On Tue, Aug 09, 2016 at 12:11:41PM -0700, Jacob Hoffman-Andrews wrote:
> 
> > 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.
> I agree not everything can be automated all the time. That's why I think
> that ACME shouldn't try to provide tools for every possible case of ToS
> agreements and updates. Here's what I'm thinking:
> 
> You are provided with a ToS URL on signup, and agree to it or you're not
> able to create an account.
>
>  - If the CA uses legal auto-update language (most common case by far),
> nothing else is required.

I think in this case we should specify that the CA MUST notify the user
of this via the ACME protocol (ie. by changing the ToS URL or similar).

It doesn't need to automatically result in a failure at the client, but
the client must be able to inform the responsible admin that this has
occurred, so that they can review the new terms.

(which probably means we need a way to signal that they are explicitly
*not* accepted - though that could just be revoking the registration
before the new terms would automatically take effect)


>  - If the CA requires human acceptance of an updated ToS, there's no way
> that ACME can automate that. The server will start returning errors with
> a link to a page the user can visit to accept a new ToS.

I'd prefer to still see this done via the client software and ACME
(ie. such as passing an --accept-tos flag to the client using the same
process as initial signup to register acceptance with the CA).

As opposed to having to visit some page from an error link and take
some action out of band.

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

Re: [Acme] Terms of service agreement changes

2016-08-09 Thread Jacob Hoffman-Andrews 

> 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.
I agree not everything can be automated all the time. That's why I think
that ACME shouldn't try to provide tools for every possible case of ToS
agreements and updates. Here's what I'm thinking:

You are provided with a ToS URL on signup, and agree to it or you're not
able to create an account.
 - If the CA uses legal auto-update language (most common case by far),
nothing else is required.
 - If the CA requires human acceptance of an updated ToS, there's no way
that ACME can automate that. The server will start returning errors with
a link to a page the user can visit to accept a new ToS.

> 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.
Yep, exactly.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Terms of service agreement changes

2016-08-08 Thread Ron 
On Sun, Aug 07, 2016 at 07:07:35PM -0700, Richard Barnes wrote:
> On Sun, Aug 7, 2016 at 8:34 AM, Hugo Landau  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
> - The CA needs to be able to update the terms/SA URL without prompting
> re-agreement

I think there's another important factor there we should be explicit
about too:

 - The end user has to find the new terms are actually still acceptable
   to them.

Which means the client software does need to always notify them that
they've changed, even if that doesn't provoke an immediate hard failure.


A change in the ToS could be anything from "our lawyers said we need to
insert this magic word in paragraph 4 that doesn't change the spirit of
this agreement in any way" to "by silently ignoring this change you
hereby agree to donate your first-born's organs to my sick cousin ..."

So whatever we do, it does need to be unambiguous about what you have
or haven't (yet) agreed to.

> 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).

This is basically what the client code that I have currently does.
It records the URI of the ToS that was agreed to, and if that later
changes in the CA header it then complains about that, asking you to
explicitly agree to the new terms again.

Having a way for the CA to signal that there is a grace period where the
old terms will still apply, and automated renewals will be accepted if
they proceed, might be useful - but that could also be implicit  ie.
the client just proceeds anyway without the

Re: [Acme] Terms of service agreement changes

2016-08-08 Thread Niklas Keller 
2016-08-08 4:07 GMT+02:00 Richard Barnes :

>
>
> On Sun, Aug 7, 2016 at 8:34 AM, Hugo Landau  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
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
>
> ___
> 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

Re: [Acme] Terms of service agreement changes

2016-08-07 Thread Richard Barnes 
On Sun, Aug 7, 2016 at 8:34 AM, Hugo Landau  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
- 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
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Terms of service agreement changes

2016-08-07 Thread Hugo Landau 
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.)

Hugo Landau

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