Re: [Acme] PRs for unparallelization and new-nonce

2016-09-08 Thread Niklas Keller
The following PR has been merged: 2016-09-09 0:15 GMT+02:00 Jacob Hoffman-Andrews : > > #163 - Make duplicate new-reg return 200 > It should return a status code 200 now and the URI in a content-location header. I have two questions: 1. Should we reallly use "Content-Location" instead of si

Re: [Acme] Application/Authorization statuses

2016-09-08 Thread Roland Bracewell Shoemaker
On 09/08/2016 10:17 AM, Richard Barnes wrote: > This sounds fine to me too, though I have some quibbles with the PRs. > > - We should get rid of "processing" globally (#186 leaves it for > authorizations) > - It seems duplicative to have "deactivated", "revoked", and "invalid". > Maybe we can k

Re: [Acme] Pre-authorization approach

2016-09-08 Thread Jacob Hoffman-Andrews
On 08/26/2016 11:19 AM, Richard Barnes wrote: > This line of argument isn't really useful. No matter what we specify > here, clients can choose to only implement a part of the spec. (There > are TLS clients that only do RSA.) Our responsibility here isn't to > make sure that there's nothing a cl

Re: [Acme] PRs for unparallelization and new-nonce

2016-09-08 Thread Jacob Hoffman-Andrews
> #181 - Add a new-nonce endpoint > https://github.com/ietf-wg-acme/acme/pull/181 LGTM > --- > #164 - Unparallelize signatures on key-change > https://github.com/ietf-wg-acme/acme/pull/164 > > We've wandered a little bit in the discussion of this PR, but there > seems to be agreement on the main

Re: [Acme] Simplifying ToS agreement

2016-09-08 Thread 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-acme/acme/pull/167 , specifically that we treat term

Re: [Acme] Simplifying ToS agreement

2016-09-08 Thread Richard Barnes
On Thu, Sep 8, 2016 at 2:40 PM, Jacob Hoffman-Andrews wrote: > Restarting the conversation on > https://github.com/ietf-wg-acme/acme/pull/167. > > An earlier version of the ACME protocol treated the new-reg URL as the > entry point for all interactions. You'd configure a client with the > new-reg

Re: [Acme] Terms of service agreement changes

2016-09-08 Thread Richard Barnes
Please go ahead! On Thu, Sep 8, 2016 at 2:02 PM, Ron wrote: > On Thu, Sep 08, 2016 at 05:22:39PM +, Salz, Rich wrote: > > 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 n

[Acme] Simplifying ToS agreement

2016-09-08 Thread Jacob Hoffman-Andrews
Restarting the conversation on https://github.com/ietf-wg-acme/acme/pull/167. An earlier version of the ACME protocol treated the new-reg URL as the entry point for all interactions. You'd configure a client with the new-reg URL, and after creating an account, you'd get URLs for other resources us

Re: [Acme] Terms of service agreement changes

2016-09-08 Thread Ron
On Thu, Sep 08, 2016 at 05:22:39PM +, Salz, Rich wrote: > 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

Re: [Acme] Pre-authorization approach

2016-09-08 Thread Salz, Rich
If anyone objects to this, and there is ensuing discussion on the WG mail list, we’ll work to resolve it. Otherwise, “silence implies agreement” and we’ll declare consensus next Tuesday. Thanks. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz From: Richard Ba

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/

Re: [Acme] Application/Authorization statuses

2016-09-08 Thread Richard Barnes
This sounds fine to me too, though I have some quibbles with the PRs. - We should get rid of "processing" globally (#186 leaves it for authorizations) - It seems duplicative to have "deactivated", "revoked", and "invalid". Maybe we can keep "invalid" as "this failed without ever being valid", but

Re: [Acme] IDN encoding

2016-09-08 Thread Richard Barnes
Sorry, missed that there was a PR attached. I put a couple of editorial comments in the PR. If you could fix those and merge master, I'll go ahead and merge it. On Mon, Aug 29, 2016 at 7:42 PM, Roland Bracewell Shoemaker < rol...@letsencrypt.org> wrote: > > > On 08/29/2016 04:36 PM, Richard Bar

Re: [Acme] Pre-authorization approach

2016-09-08 Thread Richard Barnes
Not seeing any blockers on this from the subsequent discussion. Chairs, what say you? On Fri, Aug 26, 2016 at 5:17 PM, Eric Rescorla wrote: > > > On Fri, Aug 26, 2016 at 1:33 PM, Roland Bracewell Shoemaker < > rol...@letsencrypt.org> wrote: > >> On 08/26/2016 12:25 PM, Eric Rescorla wrote: >> >

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

Re: [Acme] PRs for unparallelization and new-nonce

2016-09-08 Thread Richard Barnes
These three (#164, #181, #185) have now been merged. On Fri, Aug 26, 2016 at 11:04 PM, Richard Barnes wrote: > One more, pretty trivial one, but throwing it out there in case people > have bike shed paint they want to use: > > #185 - Change 'url' field on OOB challenge to 'href' > https://github