On Tue, Dec 8, 2020 at 8:14 PM Michael Richardson <m...@sandelman.ca> wrote:
> > 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. > Thanks for being clear! To respond: No, I don't. I'm highlighting that for a requested identifier of "baz.bar.foo.example", the CA is permitted to challenge for "bar.foo.example" or "foo.example". Indeed, some CAs, by default, will *only* challenge for "foo.example", despite that being a parent of the requested domain, because they want to reduce the effort involved to issue other certificates to that user. Now, I never said a CA "has" to, but it's certainly true that a number of CAs do, in fact, require this as their standard operating procedure, and my understanding is that this proposal was specifically about enabling such cases within ACME. That is, more generally, making a clear and well-lit path where the domain used in the authorization does not match the domain in the certificate. Is that an unreasonable understanding? It seems directly supported in the text of the draft, Section 5.4, https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.4 , example 1. > > >> 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 I am again at a loss for what you mean here / what you are attributing to me. Equally, I'm hoping that the "example.org" / "sub.example.com", as I cannot make any sense of what you said otherwise. As to your statement about me thinking the reverse, I'm hoping you can perhaps rephrase the following paragraph in Section 5.1: It may make sense to use the ACME pre-authorization flow for the subdomain use case, **however, that is an operator implementation and deployment decision.** With the ACME pre-authorization flow, the client could pre-authorize for the parent domain once, and then issue multiple newOrder requests for certificates for multiple subdomains. With the section in emphasis (**), it seems clear that this draft is not prescriptive as to whether the example in Section 5.2 (the "pre-authorization flow") needs to be required. To try to be clearer, since it seems you and I may be talking past each other and have been for some time, I'm considering the following flow: - POST /newOrder "so.me.comp.lex.example" Where the server needs to determine the appropriate set of authorizations to return for this case and the set of challenges within those authorizations. Again, this seems directly supported by Section 5.4 of the draft, https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.4 , example 1. > > 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. Can you point me to the text in the draft you're using to support this statement? As far as I can tell, there's nothing in the draft to indicate that the client asks for dns-01 authorizations. Further, there's nothing as far as I can tell that prohibits, restricts, or even allows a CA to indicate that an http-01 authorization would not be allowed.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme