Ryan, Michael, I think you are both actually in agreement and both arguing for exactly the same thing.
I think I agree that it makes more sense if the client advertises its authorized set of ADNs. e.g. if a client needs a cert or pre-authz for foo1.foo2.bar.example.com, it can offer anything from 1 to 4 different ADNs that it is capable of fulfilling. The draft as is does not preclude http-01 challenges, but I agree that the dns-01 challenge is more applicable. Does it make sense for the client to also be able to advertise the types of challenges it can fulfil? e.g. only advertise support for dns-01 but not http-01; or advertise support for both. RFC 8555 does not support this, nor does version -03 of this draft. If a client is advertising multiple ADNs it can authorize, should the supported challenge type be per ADN? e.g. dns-01 and http-01 for foo1.foo2.bar.example.com but only dns-01 for example.com? Is this flexibility in any way useful, or just likely to lead to confusion and implementation bugs? For sure, the way the draft is currently written, if a client places an order for a subdomain, and the server issues a single challenge for a parent ADN (which could be the BDN/Base Domain Name), then this will result in frequent failures as the client is not authorized to control the parent ADN/BDN. From: Ryan Sleevi <ryan-i...@sleevi.com> Sent: 10 December 2020 03:51 To: Michael Richardson <m...@sandelman.ca> Cc: Ryan Sleevi <ryan-i...@sleevi.com>; Owen Friel (ofriel) <ofr...@cisco.com>; Felipe Gasper <fel...@felipegasper.com>; acme@ietf.org Subject: Re: [Acme] acme subdomains open items On Tue, Dec 8, 2020 at 8:14 PM Michael Richardson <m...@sandelman.ca<mailto: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<http://example.org>, followed by an order for sub.example.com<http://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<http://example.org>" / "sub.example.com<http://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<http://example.org>"), in order to authorize > "so.me.comp.lex.example" (in the illustration here, "sub.example.org<http://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<http://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
