Re: [Acme] Proactive vs On-Finalization Certificate Issuance

Hi Andrew, Thanks for the follow-up. > There's another reason I prefer proactive issuance: I think the server > should automatically issue a new certificate if an application's > current certificate is about to expire and its authorizations are still > valid. This lets you create an application

Re: [Acme] Clarifying "new-x" resources paragraph

This looked fine to me, so I just merged it. On Thu, Aug 25, 2016 at 4:20 PM, Daniel McCarney wrote: > Hello again, > > I've taken a crack at clarifying what I found to be a confusing paragraph > from > Section 6.1 "Resources"[0]: > > > For the "new-X" resources above, the server MUST have exact

[Acme] PRs for unparallelization and new-nonce

Hey all, Going through PRs today, trying to see where we can make progress. I've already merged several that seemed non-controversial [1]. There are two more where I think we have agreement, but I wanted to give people a few days to opine: --- #181 - Add a new-nonce endpoint https://github.com/

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

Folks, Please take a look and send feedback. /r$, co-chair -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz From: Richard Barnes [mailto:r...@ipv.sx] Sent: Friday, August 26, 2016 1:17 PM To: acme@ietf.org Subject: [Acme] PRs for unparallelizati

Re: [Acme] Pre-authorization approach

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 client can skip, it's to make sure that a client that wa

Re: [Acme] Pre-authorization approach

As co-chair: Let’s think about this over the weekend and – if you have something new, please post early next week. Perhaps review the mailing list archives before posting. Then we’ll try to determine consensus at the end of the week. -- Senior Architect, Akamai Technologies IM: richs...@jabbe

Re: [Acme] Terms of service agreement changes

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 Based on tha

Re: [Acme] Proactive vs On-Finalization Certificate Issuance

On 08/25/2016 02:41 PM, Andrew Ayer wrote: > On Thu, 25 Aug 2016 13:57:25 -0400 > Daniel McCarney wrote: > >> In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems >> to agree >> that there should be only one issuance method to simplify client >> behaviours, though he favours proa

Re: [Acme] Proactive vs On-Finalization Certificate Issuance

On 08/25/2016 03:15 PM, Richard Barnes wrote: > > > On Thu, Aug 25, 2016 at 5:41 PM, Andrew Ayer > wrote: > > On Thu, 25 Aug 2016 13:57:25 -0400 > Daniel McCarney > wrote: > > > In the earlier "Re: [Acme] Precondit

Re: [Acme] Terms of service agreement changes

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

Re: [Acme] Pre-authorization approach

On 08/06/2016 10:49 AM, Eric Rescorla wrote: > > > On Sat, Aug 6, 2016 at 10:36 AM, Jacob Hoffman-Andrews > wrote: > > > I also think EKR's comment that we need the ability to authorize domain > names without immediately issuing is a solid one*. So I think we shoul

Re: [Acme] Pre-authorization approach

On Fri, Aug 26, 2016 at 12:09 PM, Roland Bracewell Shoemaker < rol...@letsencrypt.org> wrote: > On 08/06/2016 10:49 AM, Eric Rescorla wrote: > > > > > > On Sat, Aug 6, 2016 at 10:36 AM, Jacob Hoffman-Andrews > > wrote: > > > > > > I also think EKR's comment that we need t

Re: [Acme] Pre-authorization approach

On 08/26/2016 12:25 PM, Eric Rescorla wrote: > > > On Fri, Aug 26, 2016 at 12:09 PM, Roland Bracewell Shoemaker > mailto:rol...@letsencrypt.org>> wrote: > > On 08/06/2016 10:49 AM, Eric Rescorla wrote: > > > > > > On Sat, Aug 6, 2016 at 10:36 AM, Jacob Hoffman-Andrews

Re: [Acme] Pre-authorization approach

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: > > > > > > On Fri, Aug 26, 2016 at 12:09 PM, Roland Bracewell Shoemaker > > mailto:rol...@letsencrypt.org>> wrote: > > > > On 08/06/2016 10:49 AM, Eric R

[Acme] Application/Authorization statuses

Currently the specification defines the statuses 'unknown' and 'processing' as valid for both applications and authorizations. Given that both also have 'valid', 'pending', and 'invalid' I can't really see a reason to keep 'unknown' and for applications in particular the meaning of 'processing' see

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

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.com/ietf-wg-acme/acme/pull/185 I noticed as I was implementing the oob-01 challenge that in the current spec, there are