Re: [Acme] Simplifying ToS agreement

2016-10-02 Thread Richard Barnes
On Tue, Sep 13, 2016 at 11:56 AM, Jacob Hoffman-Andrews wrote: > > > Anything that isn't tested Will be broken. We can't fix that in the > > protocol, but we can fix it by adding tests :) > We can also fix it by deleting unnecessary things, which is the best and > most reliable

Re: [Acme] Simplifying ToS agreement

2016-09-29 Thread Jacob Hoffman-Andrews
On 09/27/2016 12:17 AM, Hugo Landau wrote: > But right now you can use Let's Encrypt without providing any means of > out-of-band communication, so it's not safe to assume that such a > mechanism — e. mail or otherwise — will be available. This is exactly why we chose to write our Subscriber

Re: [Acme] Simplifying ToS agreement

2016-09-26 Thread Hugo Landau
> The most likely out-of-band channel is email, right? So the CA would > send out email informing their customers that there's a new ToS, and the > customer needs to explicitly agree to it in the next N days, or they > will be unable to use the service. > > There are a couple of options the CA

Re: [Acme] Simplifying ToS agreement

2016-09-26 Thread Jacob Hoffman-Andrews
On 09/24/2016 06:03 PM, Hugo Landau wrote: >> Very specifically, I am trying to make life easier for clients that >> hardcode the agreement URL. > How can hardcoding the URL ever be legitimate? Sorry, this was one of those worst-case typos. It should have read: "Very specifically, I am *not*

Re: [Acme] Simplifying ToS agreement

2016-09-25 Thread Ron
On Mon, Sep 26, 2016 at 05:53:26AM +0100, Hugo Landau wrote: > > I don't see a problem with having the directory show that the current > > ToS is "version 3", and the registration object show that explicit > > assent was obtained for "version 1", and leaving it up to the legal > > acrobatics in

Re: [Acme] Simplifying ToS agreement

2016-09-25 Thread Hugo Landau
> I don't see a problem with having the directory show that the current > ToS is "version 3", and the registration object show that explicit > assent was obtained for "version 1", and leaving it up to the legal > acrobatics in the text of version 1 to say that explicit assent isn't > required for

Re: [Acme] Simplifying ToS agreement

2016-09-25 Thread Ron
On Sun, Sep 25, 2016 at 02:03:21AM +0100, Hugo Landau wrote: > I think the TOS URI mechanism should be preserved, and the specification > should be changed to state that if no new act of assent is required, > the URI stored in a registration should be updated to match it > automatically. I'm

Re: [Acme] Simplifying ToS agreement

2016-09-24 Thread Hugo Landau
I think the TOS URI mechanism should be preserved, and the specification should be changed to state that if no new act of assent is required, the URI stored in a registration should be updated to match it automatically. > I think this may be where we are not understanding each other. This is >

Re: [Acme] Simplifying ToS agreement

2016-09-19 Thread Jacob Hoffman-Andrews
On 09/17/2016 02:08 AM, Ron wrote: > > And if the answer to that is "we do automate it", then the important > question is: Does this even remotely satisfy the actual requirement? IANAL, but the feedback we've gotten so far is it is reasonable for someone to agree to terms of service through an

Re: [Acme] Simplifying ToS agreement

2016-09-13 Thread Niklas Keller
> > I would argue that we don't need to support it explicitly, because > returning an error with a link to an out-of-band URL for re-agreeing is > sufficient, and matches the most likely flow. This is an interesting idea. Maybe that's also something we could to for the initial registration?

Re: [Acme] Simplifying ToS agreement

2016-09-13 Thread Jacob Hoffman-Andrews
> Anything that isn't tested Will be broken. We can't fix that in the > protocol, but we can fix it by adding tests :) We can also fix it by deleting unnecessary things, which is the best and most reliable way to avoid bugs. That's why I think this is the right approach.

Re: [Acme] Simplifying ToS agreement

2016-09-12 Thread Ron
On Sat, Sep 10, 2016 at 07:13:23PM -0400, Richard Barnes wrote: > OK, let me clarify my invariants here: I think we can't get away with not > supporting the case where the CA updates the terms and needs clients to > re-agree. I also feel like the current proposal in #167 is semantically >

Re: [Acme] Simplifying ToS agreement

2016-09-12 Thread Jacob Hoffman-Andrews
On 09/10/2016 04:13 PM, Richard Barnes wrote: > OK, let me clarify my invariants here: I think we can't get away with > not supporting the case where the CA updates the terms and needs > clients to re-agree. I would argue that we don't need to support it explicitly, because returning an error with

Re: [Acme] Simplifying ToS agreement

2016-09-10 Thread Josh Aas
I just want to add that when Jacob says "this is a field that is updated very rarely and therefore is likely to break poorly implemented clients if it changes," he is not talking about theoretical breakage. When we updated the Let's Encrypt subscriber agreement for the first time some clients

Re: [Acme] Simplifying ToS agreement

2016-09-09 Thread Niklas Keller
2016-09-08 23:56 GMT+02:00 Jacob Hoffman-Andrews : > On 09/08/2016 02:32 PM, Richard Barnes wrote: > > So what, we should just delete it? Are you arguing that this > functionality is unnecessary? > > I'm arguing for the changes in https://github.com/ietf-wg-acm > e/acme/pull/167,