[Acme] security concern for dns challenge

Hi, When example.com zone and its child zone, www.example.com, are hosted in the same DNS server, most of DNS server implementations response authoritative answers to queries for the child zone, even if the parent does not delegate the child. Some DNS hosting providers do not confirm whether the

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 p

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 chan

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 https://www.ietf.org/mailman/lis

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 ah

Re: [Acme] Preconditions

I think there's a possibility we could implement a lot of the desired functionality without preconditions or changing the reg-authz-cert flow. The main benefits initially mentioned for preconditions were payments, wildcards, and CA issuance flows. To implement payments, it seems like we could use

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 11:16 AM, Richard Barnes wrote:

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 wrote: > > That

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 why

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 wanted the CA to be

Re: [Acme] Preconditions

> Does it make sense for the server to be allowed to return multiple exclusive sets of authorizations that could lead to issuance, in order to avoid knowledge of the issuance rules in the client? This makes sense, but I think it would add a fair amount of complexity for uncertain benefit. I'd rath

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 > rush this into