Re: [Acme] Preconditions

On Sun, 17 Jul 2016 19:38:40 -0700 Andrew Ayer wrote: > > [[ Open issue: There are two possible behaviors for the CA here. > > Either (a) the CA automatically issues once all the requirements are > > fulfilled, or (b) the CA waits for confirmation from the client that > >

Re: [Acme] Preconditions

On Thu, 7 Jul 2016 21:58:35 -0400 Richard Barnes wrote: > OK, I have updated the preconditions PR to reflect this discussion. > It's more invasive than I thought going in, but I think it hangs > together. > > https://github.com/ietf-wg-acme/acme/pull/124 I like the direction that

Re: [Acme] Preconditions

On 9 July 2016 at 08:00, Peter Eckersley wrote: > With a bit of warning I might have been able to put that together for this > deadline. Please don't treat meeting deadlines as anything special. Generate discussion and pull requests at any time. The reason we have the deadline is

Re: [Acme] Preconditions

On Fri, Jul 08, 2016 at 01:59:03PM -0700, Jacob Hoffman-Andrews wrote: > > Would you, or Rich as co-chair, be willing to give two weeks advance > notice on the list of upcoming document deadlines? Yes, that would probably be useful. AFAICT we may still need to make a revision that suggests a

Re: [Acme] Preconditions

Jeff raises a good point. There are a number of people here, including myself, who are not active in the IETF in general, and so aren't aware of upcoming meetings and deadlines. From this perspective, progress on the spec seems to come in sudden spurts of activity without adequate time for

Re: [Acme] Preconditions

On 07/07/2016 05:18 PM, Salz, Rich wrote: > That's the LetsEncrypt protocol, not the IETF ACME protocol. We're not > here to polish the staples and rubber-stamp. /r$, speaking as > co-chair. -- Senior Architect, Akamai I agree with this. Let's Encrypt has planned all along to make some breaking

Re: [Acme] Preconditions

Oh, left out: or even enough time for people to read this email to know they need to object. I just happened to be up. On Fri, Jul 8, 2016 at 5:07 AM Jeff Hodges wrote: > You sent this at 7 PM Pacific which is after hours and are expecting > feedback by 9 AM Pacific. I

Re: [Acme] Preconditions

You sent this at 7 PM Pacific which is after hours and are expecting feedback by 9 AM Pacific. I don't think that's nearly enough time to vet the latest changes you've made. On Thu, Jul 7, 2016 at 6:58 PM Richard Barnes wrote: > OK, I have updated the preconditions PR to reflect

Re: [Acme] Preconditions

OK, I have updated the preconditions PR to reflect this discussion. It's more invasive than I thought going in, but I think it hangs together. https://github.com/ietf-wg-acme/acme/pull/124 If there are not major objections before tomorrow morning EST, I'm going to go ahead and merge it. We can

Re: [Acme] Preconditions

> There are dozens of projects that will need to rework their code if we > restructure the protocol, including most of these and probably a lot that > aren't listed: > > https://letsencrypt.org/docs/client-options/ That's the LetsEncrypt protocol, not the IETF ACME protocol. We're not here to

Re: [Acme] Preconditions

On Thu, Jul 07, 2016 at 06:27:48PM -0400, Richard Barnes wrote: > So to be blunt: You're saying that some of what we want could be achieved > by hacks within the existing model, rather than getting all of what we want > by changing the model :) > > I really think it's cleaner at this point to

Re: [Acme] Preconditions

> I really think it's cleaner at this point to change the model.  There's not > that much deployed code yet, so we should go ahead and get things right. Not as chair: strongly agree. ___ Acme mailing list Acme@ietf.org

Re: [Acme] Preconditions

So to be blunt: You're saying that some of what we want could be achieved by hacks within the existing model, rather than getting all of what we want by changing the model :) I really think it's cleaner at this point to change the model. There's not that much deployed code yet, so we should go

Re: [Acme] Preconditions

On Thu, Jul 7, 2016 at 5:10 PM, Jacob Hoffman-Andrews wrote: > Re-adding the list. I dropped it by accident. > > On 07/07/2016 01:50 PM, Richard Barnes wrote: > > > > On Thu, Jul 7, 2016 at 3:38 PM, Jacob Hoffman-Andrews < > j...@eff.org> wrote: > >> On 07/07/2016

Re: [Acme] Preconditions

(Resending Richard's mail where the list was still dropped, to make the flow of converstaion clearer): On 07/07/2016 01:50 PM, Richard Barnes wrote: > On Thu, Jul 7, 2016 at 3:38 PM, Jacob Hoffman-Andrews > > wrote: > > On 07/07/2016 11:16 AM, Richard Barnes

Re: [Acme] Preconditions

(Resending mail where the list got dropped, to make the flow of conversation clearer): On 07/07/2016 11:16 AM, Richard Barnes wrote: > That wasn't my intent. Rather, I wanted the CA to be able to say, > e.g., "you have to provide a contact". Does that much seem useful? Ah, now I get it. But

Re: [Acme] Preconditions

Re-adding the list. I dropped it by accident. On 07/07/2016 01:50 PM, Richard Barnes wrote: > > > On Thu, Jul 7, 2016 at 3:38 PM, Jacob Hoffman-Andrews > wrote: > > On 07/07/2016 11:16 AM, Richard Barnes wrote: > > That wasn't my intent. Rather, I

Re: [Acme] Preconditions

On Wed, Jul 6, 2016 at 2:38 PM, Jacob Hoffman-Andrews wrote: > I think the general concept is good, and if we go this route I agree > that it should replace new-authz. However, I think there are significant > details to be worked out, and Eric's feedback is good. I don't want to >

Re: [Acme] Preconditions

On Wed, Jul 6, 2016 at 2:54 PM, Jonathan Rudenberg wrote: > It seems that there are potentially multiple valid sets of authorizations > that are mutually exclusive. > > Consider a request for a certificate that has three SANs: a.example.com, > b.example.com, c.example.com

Re: [Acme] Preconditions

It seems that there are potentially multiple valid sets of authorizations that are mutually exclusive. Consider a request for a certificate that has three SANs: a.example.com, b.example.com, c.example.com There are two valid paths to issuance: validate example.com, or validate the three SANs

Re: [Acme] Preconditions

I think the general concept is good, and if we go this route I agree that it should replace new-authz. However, I think there are significant details to be worked out, and Eric's feedback is good. I don't want to rush this into the spec because we have a document deadline coming up. I'd rather

Re: [Acme] Preconditions

On Wed, Jul 6, 2016 at 12:52 PM, Eric Rescorla wrote: > > > On Wed, Jul 6, 2016 at 8:01 AM, Richard Barnes wrote: > >> In preparation for the impending draft deadline, I'm trying to finalize >> close this out. It seems like there's some positive reaction to the >>

Re: [Acme] Preconditions

Speaking as an individual, not a chair, this seems like the right trade-off (a bit of complexity for way more generality) to make. I am in favor. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme