Re: [Acme] acme subdomains open items

[Ryan Sleevi <[e-mail]>]

On Tue, Dec 8, 2020 at 8:14 PM Michael Richardson <[e-mail]> 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.