Re: [Acme] acme subdomains open items
Ryan Sleevi wrote: >> The client has control over lex.example, but and can prove it with dns-01 >> TXT >> record placed at _acme-challenge.lex.example. Why does it matter whether >> it >> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example. >> or an.other.comp.lex.example?? > The mistake you’ve made here is assuming the client has control over > lex.example, and thus all subdomains. The point of all of this is that is > an unrealistic assumption: the client may only have control over the DNS > zone at so.me.comp.lex.example or they might have control at the > me.comp.lex.example, but no control at comp.lex.example. I don't understand. If the client doesn't control lex.example, then why would it expect to get any kind of control of that? Same as without subdomains. > The existing approach with ACME assumes and expects that validation will be > done at the FQDN (this is an oversimplification, but the nuance here isn’t > as important). Yes, the FULLY-QUALIFIED. Not the public name. dns-01 works just fine today for so.me.comp.lex.example. The client does not demonstrate control over lex.example using dns-01 when it asks for so.me.comp.lex.example. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme subdomains open items
On Tue, Dec 8, 2020 at 4:33 PM Michael Richardson wrote: > > Ryan Sleevi wrote: > >> The client has control over lex.example, but and can prove it with > dns-01 > >> TXT > >> record placed at _acme-challenge.lex.example. Why does it matter > whether > >> it > >> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example. > >> or an.other.comp.lex.example?? > > > > The mistake you’ve made here is assuming the client has control over > > lex.example, and thus all subdomains. The point of all of this is > that is > > an unrealistic assumption: the client may only have control over the > DNS > > zone at so.me.comp.lex.example or they might have control at the > > me.comp.lex.example, but no control at comp.lex.example. > > I don't understand. > If the client doesn't control lex.example, then why would it expect to get > any kind of control of that? > Same as without subdomains. > Alas, I'm equally at a loss to understand what you're asking here, as I can't make much sense of your question? > > The existing approach with ACME assumes and expects that validation > will be > > done at the FQDN (this is an oversimplification, but the nuance here > isn’t > > as important). > > Yes, the FULLY-QUALIFIED. Not the public name. > dns-01 works just fine today for so.me.comp.lex.example. > > The client does not demonstrate control over lex.example using dns-01 when > it > asks for so.me.comp.lex.example. > Is that not literally what this draft is proposing (e.g. https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.2 ) ? In the pre-auth flow, the client affirmatively requests "lex.example" (In the illustration here, "example.org"), in order to authorize "so.me.comp.lex.example" (in the illustration here, "sub.example.org"). That is, the client explicitly declares their naming scope. However, in the pre-auth flow, you have to know that the client will want to be able to /newOrder for "sub.example.org" (as Step 2 in the illustration), since you shouldn't return http-01 authorizations in Step 1 for this case. For authorizations created in response to a request (i.e. the non-preauth flow, which this draft explicitly states is allowed in 5.1), the CA has to make a determination about what authorizations to issue, and the state to track all of those pending authorizations created, which gets us back to the discussion. The significant majority of CAs, for the majority of certificates issued by these CAs, totally rely upon authorizing "lex.example" in order to issue certificates for "so.me.comp.lex.example" (whether using DNS-01, email, or other). So I'm not sure what you mean by "does not demonstrate control". Hopefully, this reply helps clarify, but if you still aren't sure, I'm hoping you could be clearer on the uncertainty and I'll do my best to rephrase. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] acme subdomains open items
Ryan Sleevi wrote: >> Ryan Sleevi wrote: >> >> The client has control over lex.example, but and can prove it with >> dns-01 >> >> TXT >> >> record placed at _acme-challenge.lex.example. Why does it matter >> whether >> >> it >> >> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example. >> >> or an.other.comp.lex.example?? >> >> >> > The mistake you’ve made here is assuming the client has control over >> > lex.example, and thus all subdomains. The point of all of this is >> that is >> > an unrealistic assumption: the client may only have control over the >> DNS >> > zone at so.me.comp.lex.example or they might have control at the >> > me.comp.lex.example, but no control at comp.lex.example. >> >> I don't understand. >> If the client doesn't control lex.example, then why would it expect to get >> any kind of control of that? >> Same as without subdomains. >> > Alas, I'm equally at a loss to understand what you're asking here, as I > can't make much sense of your question? dns-01 challenges for bar.bar.foo.example do not have to show control over foo.example. Yet, you seem to think that they do. >> The client does not demonstrate control over lex.example using dns-01 when >> it >> asks for so.me.comp.lex.example. > Is that not literally what this draft is proposing (e.g. > https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.2 ) ? It demonstrates control (during the authorization) for lex.example, which allows it to fullfil orders for so.me.comp.lex.example. Your line of questioning implies you think the reverse. 5.2 clearly shows authorization for example.org, followed by an order for sub.example.com > In the pre-auth flow, the client affirmatively requests "lex.example" (In > the illustration here, "example.org"), in order to authorize > "so.me.comp.lex.example" (in the illustration here, "sub.example.org"). > That is, the client explicitly declares their naming scope. > However, in the pre-auth flow, you have to know that the client will want > to be able to /newOrder for "sub.example.org" (as Step 2 in the > illustration), since you shouldn't return http-01 authorizations in Step 1 > for this case. how are http-01 authorizations involved? The client asks for dns-01 authorizations. > The significant majority of CAs, for the majority of certificates issued by > these CAs, totally rely upon authorizing "lex.example" in order to issue > certificates for "so.me.comp.lex.example" (whether using DNS-01, email, or > other). So I'm not sure what you mean by "does not demonstrate > control". I think that I have typoed above! :-) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
