Subject: [Acme] acme subdomains open items

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Fri, 4 Dec 2020 07:21:58 +0000

Hi all,

As recommended by the chairs at IETF109, bring the two open items to the list for discussion. These were raised by Felipe and Ryan previously.

1: Does the client need a mechanism to indicate that they want to authorize a parent domain and not the explicit subdomain identifier? Or a mechanism to indicate that they are happy to authorize against a choice of identifiers?

E.g. for foo1.foo2.bar.example.com, should the client be able to specify anywhere from 1 to 4 identifiers they are willing to fulfil challenges for?

2: Does the server need a mechanism to provide a choice of identifiers to the client and let the client chose which challenge to fulfil?

E.g. for foo1.foo2.bar.example.com, should the server be able to specify anywhere from 1 to 4 identifiers that the client can pick from to fulfil?

Both 1 and 2 require JSON object definition changes. Currently, the document only defines how a client can submit a newOrder / newAuthz for a subdomain, and the server can chose any one parent identifier that it requires a challenge fulfilment on

Owen

https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01

https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4

---

From: Felipe Gasper <[email-masked]>
Date: Fri, 4 Dec 2020 08:34:30 -0500

I wasn’t part of IETF 109 .. was it discussed simply to give CAs the ability to choose whether it tries authz against parent domains without the client’s requesting it?

This is how our (non-ACME) Sectigo integration works currently, and it suits us well.

-F

> On Dec 4, 2020, at 02:23, Owen Friel (ofriel) <ofriel=[email-masked]> wrote:
> 
> 
> Hi all,
>  
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Fri, 4 Dec 2020 15:25:05 +0000

That is what is currently documented – the server simply picks the one domain that it wants the client to fulfil the challenge against.

That was presented as the current documented approach. And I also presented the open questions if we needed to build flexibility in client request and/or server response. There were no concrete opinions as far as I recall (waiting on the exact minutes) and Rich said to bring the qs to the mailer for further discussion.

Cheers,
Owen

From: Acme <[email-masked]> On Behalf Of Felipe Gasper
Sent: 04 December 2020 21:35
To: Owen Friel (ofriel) <ofriel=[email-masked]>
Cc: [email-masked]
Subject: Re: [Acme] acme subdomains open items

-F

On Dec 4, 2020, at 02:23, Owen Friel (ofriel) <ofriel=[email-masked]<mailto:ofriel=[email-masked]>> wrote:

Hi all,

Owen

_______________________________________________
Acme mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/acme

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 4 Dec 2020 14:26:35 -0500

Thanks for bringing it to the list, Owen.

This is something we're trying to lock down in the CA/B Forum, at least
with respect to the 'http-01' method, by making it clear that, like
tls-alpn-01, it cannot be used as an Authorization Domain Name (i.e. a
domain and all of its descendents), only as an FQDN.

So this method primarily is for the 'dns-01' method, which seems to suggest
that, at a minimum, the ACME server needs to indicate to the ACME client
what modifications it will accept, since the ACME client will need to
actually modify the DNS record at the appropriate label. If the server only
chooses a single label, then it seems both likely and possible that the
server may choose a dns-01 challenge that the client cannot fulfill (e.g.
the client can only modify subdomain.example.com and descendents, but the
server/CA chooses to challenge against example.com)

So I *think* it would benefit from having the server be able to issue
challenges against several identifiers, and communicate that to the client,
which seems to argue "Yes" for your question #2.

Equally in this scenario, I think you're asking whether or not the client
should be able to indicate its capabilities to the ACME server, for
selecting appropriate challenges. If a client is using dns-01 and can only
modify subdomain.example.com, it doesn't benefit the client at all if the
server chooses to also allow example.com. The question is whether there's a
security risk in doing so; that is, should the client be able to
affirmatively restrict the server or does it not matter.

Does that accurately capture things?

On Fri, Dec 4, 2020 at 10:25 AM Owen Friel (ofriel) <ofriel=
[email-masked]> wrote:

> That is what is currently documented – the server simply picks the one
> domain that it wants the client to fulfil the challenge against.
>
>
>
> That was presented as the current documented approach. And I also
> presented the open questions if we needed to build flexibility in client
> request and/or server response. There were no concrete opinions as far as I
> recall (waiting on the exact minutes) and Rich said to bring the qs to the
> mailer for further discussion.
>
>
>
> Cheers,
>
> Owen
>
>
>
>
>
> *From:* Acme <[email-masked]> *On Behalf Of *Felipe Gasper
> *Sent:* 04 December 2020 21:35
> *To:* Owen Friel (ofriel) <ofriel=[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Acme] acme subdomains open items
>
>
>
> I wasn’t part of IETF 109 .. was it discussed simply to give CAs the
> ability to choose whether it tries authz against parent domains without the
> client’s requesting it?
>
>
>
> On Dec 4, 2020, at 02:23, Owen Friel (ofriel) <
> ofriel=[email-masked]> wrote:
>
> 
>
> Hi all,
>
>
>
> As recommended by the chairs at IETF109, bring the two open items to the
> list for discussion. These were raised by Felipe and Ryan previously.
>
>
>
> 1: Does the client need a mechanism to indicate that they want to
> authorize a parent domain and not the explicit subdomain identifier? Or a
> mechanism to indicate that they are happy to authorize against a choice of
> identifiers?
>
>
>
> E.g. for foo1.foo2.bar.example.com, should the client be able to specify
> anywhere from 1 to 4 identifiers they are willing to fulfil challenges for?
>
>
>
> 2: Does the server need a mechanism to provide a choice of identifiers to
> the client and let the client chose which challenge to fulfil?
>
>
>
> E.g. for foo1.foo2.bar.example.com, should the server be able to specify
> anywhere from 1 to 4 identifiers that the client can pick from to fulfil?
>
>
>
> Both 1 and 2 require JSON object definition changes. Currently, the
> document only defines how a client can submit a newOrder / newAuthz for a
> subdomain, and the server can chose any one parent identifier that it
> requires a challenge fulfilment on
>
>
>
> Owen
>
>
>
>

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Mon, 7 Dec 2020 02:32:16 +0000

From: Ryan Sleevi <[email-masked]>
Sent: 05 December 2020 03:27
To: Owen Friel (ofriel) <[email-masked]>
Cc: Felipe Gasper <[email-masked]>; [email-masked]
Subject: Re: [Acme] acme subdomains open items

This is something we're trying to lock down in the CA/B Forum, at least with respect to the 'http-01' method, by making it clear that, like tls-alpn-01, it cannot be used as an Authorization Domain Name (i.e. a domain and all of its descendents), only as an FQDN.

So this method primarily is for the 'dns-01' method, which seems to suggest that, at a minimum, the ACME server needs to indicate to the ACME client what modifications it will accept, since the ACME client will need to actually modify the DNS record at the appropriate label. If the server only chooses a single label, then it seems both likely and possible that the server may choose a dns-01 challenge that the client cannot fulfill (e.g. the client can only modify subdomain.example.com<http://subdomain.example.com> and descendents, but the server/CA chooses to challenge against example.com<http://example.com>)

So I *think* it would benefit from having the server be able to issue challenges against several identifiers, and communicate that to the client, which seems to argue "Yes" for your question #2.

[ofriel] Are there any benefits or security advantages in #1 (client giving server options) vs. #2 (server giving client options)? With #2, the client does not have to explicitly divulge any information about its level of domain control. The server gives the client a set of options, and the client decides what to do. Obviously, if it fulfils the challenge against a parent Authorized Domain Name, then it has implicitly indicated control over that domain.

Equally in this scenario, I think you're asking whether or not the client should be able to indicate its capabilities to the ACME server, for selecting appropriate challenges. If a client is using dns-01 and can only modify subdomain.example.com<http://subdomain.example.com>, it doesn't benefit the client at all if the server chooses to also allow example.com<http://example.com>. The question is whether there's a security risk in doing so; that is, should the client be able to affirmatively restrict the server or does it not matter.

[ofriel] Yes, that is exactly what I am getting at. Perhaps the question #1 should be phrased more accurately something like: Does the client need a mechanism to indicate to the server that it is capable of and authorized to fulfil challenges against the requested subdomain FQDN, as well as some or all of the parent Authorized Domain Names (potentially up to and including the Base Domain Name).

TBH I have no thought about the security risk of a client indicating to the server that it has control over parent domains, potentially including the Base Domain Name. What does the CA/B currently think about this?

[ofriel] Exactly the questions I am asking.

On Fri, Dec 4, 2020 at 10:25 AM Owen Friel (ofriel) <ofriel=[email-masked]<mailto:[email-masked]>> wrote:
That is what is currently documented – the server simply picks the one domain that it wants the client to fulfil the challenge against.

Cheers,
Owen

From: Acme <[email-masked]<mailto:[email-masked]>> On Behalf Of Felipe Gasper
Sent: 04 December 2020 21:35
To: Owen Friel (ofriel) <ofriel=[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Acme] acme subdomains open items

-F

Hi all,

E.g. for foo1.foo2.bar.example.com<http://foo1.foo2.bar.example.com>, should the client be able to specify anywhere from 1 to 4 identifiers they are willing to fulfil challenges for?

E.g. for foo1.foo2.bar.example.com<http://foo1.foo2.bar.example.com>, should the server be able to specify anywhere from 1 to 4 identifiers that the client can pick from to fulfil?

Owen

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 6 Dec 2020 23:21:49 -0500

On Sun, Dec 6, 2020 at 9:32 PM Owen Friel (ofriel) <[email-masked]> wrote:

> [ofriel] Are there any benefits or security advantages in #1 (client
> giving server options) vs. #2 (server giving client options)? With #2, the
> client does not have to explicitly divulge any information about its level
> of domain control. The server gives the client a set of options, and the
> client decides what to do. Obviously, if it fulfils the challenge against a
> parent Authorized Domain Name, then it has implicitly indicated control
> over that domain.
>
🤷‍♂️

If there is a limit to the number of challenges, it seems it benefits from
the client choosing/advertising. Until the challenge is complete, the
server has to maintain state for (effectively) an unauthorized user, while
in the client-advertise scenario, there’s no server state other than what
the server chooses to use.

Further, if we assume that say there are ten domain labels, but the server
is only willing to maintain state for five (as a window), then it’s not
clear how the client can request the server sends the first five rather
than the last five. Having the client advertise its capabilities let’s the
client choose the window, and if the server rejects all of them, the client
at least can try again with a different window (e.g. the last five labels).

I don’t know how compelling this is, but my assumption here is that because
we’re discussing effectively DNS-01 challenges, the client is limited in
its abilities, and so the client should indicate it’s capabilities, and
minimize server state.

> server chooses to also allow example.com. The question is whether there's
> a security risk in doing so; that is, should the client be able to
> [ofriel] Yes, that is exactly what I am getting at. Perhaps the question
> #1 should be phrased more accurately something like: Does the client need a
> mechanism to indicate to the server that it is capable of and authorized to
> fulfil challenges against the requested subdomain FQDN, as well as some or
> all of the parent Authorized Domain Names (potentially up to and including
> the Base Domain Name).
>
>
>
> TBH I have no thought about the security risk of a client indicating to
> the server that it has control over parent domains, potentially including
> the Base Domain Name. What does the CA/B currently think about this?
>
I mean, right now there’s no rules on which party selects the Authorization
Domain Name, when an ADN is allowed. The CA still has to validate the ADN
against the rules.

Having the client indicate minimizes CA processing before validation; each
of the advertised ADNs can really be treated as independent FQDNs (that is,
largely opaquely), and only after validation of the challenge does the CA
do any processing on the domain label, to ensure it’s an ADN for the
(originally requested) FQDN.

That’s why my slight preference was to have the client advertise.
Processing after validation seemed preferable to processing prior to
validation, and it also seemed useful to let the client advertise
capabilities directly to let the server reduce any stored state. However, I
can equally imagine an asinine implementation of client-advertise that
requests a cert for “www.example.com” but let’s the client set the ADN as “
example.net” and, post-validation of example.net, fails to check that “
example.net” matches “example.com”. Or does something equally silly like
allowing “prefix.example” to authorize “not-actually-a-prefix.example”.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Dec 2020 08:30:26 -0500

Ryan, I'm not really following this conversation.
Probably my mental model of dns-01 challenges is lacking.
The word "window" does not appear in RFC8555 or acme-subdomains, so that's
your word, I think.

    > at least can try again with a different window (e.g. the last five

I don't really understand this at all.
I think that we are discussing so.me.comp.lex.example.

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??

One thing that just occured to me is whether or not there is any value in the
dns-01 challenge remaining in the DNS after the authorization.
What I'm thinking is that the CA could offload some of it's state for the
client to store for it.

    > capabilities directly to let the server reduce any stored state.

    > However, I

I can't see how any of these things are anything other than serious bugs.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 7 Dec 2020 09:29:03 -0500

> 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.

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). The point is that if the server decides to challenge
lex.example or comp.lex.example, it will fail for this client, so that’s
why we need some form of either/or or both/and of multiple challenges and a
client indicated set of capabilities.

The window is simply which labels you select: the example you chose has
five labels, so whether we select the “first” two domains (“so” and “me”
working from most to least specific) or the “middle” two (“comp” and “lex”)
matters. Similarly, it’s valid to issue a challenge for “example” in all of
its glory: this comes up with ICANN Spec-9/Spec-13 gTLDs, and so it’s
useful to allow the client to say “no, really, validate the *entire*
namespace”. So even if the server challenged “lex.example” that could be
the wrong level.

One thing that just occured to me is whether or not there is any value in
> the

I don’t think it’s reasonable at all to make changes like that. It would
either limit issuance of multiple independent certificates within a time
period (collision on _acme-validation) or would encourage the use of random
values in the labels.

> I can't see how any of these things are anything other than serious bugs.

I didn’t say they weren’t. But just like C is a fundamentally insecure
language that no one ethically responsible or security conscious should
choose as a first choice for new code, the ergonomics of the decisions here
are worth pointing out. There are Top 10 CAs that are misissuing
certificates because they found it “confusing” to locate requirements [1]
or manually implement the CAA lookup algorithm by hand for every request
[2]. My intent in pointing these out is to acknowledge that we have to
contemplate the worst possible implementations, and view the risks through
that lens, when thinking about risks or tradeoff. We simply can’t assume a
competent implementation, unfortunately.

[1]
https://bugzilla.mozilla.org/show_bug.cgi?id=1662807
[2]
https://bugzilla.mozilla.org/show_bug.cgi?id=1651026#c12

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Dec 2020 16:33:03 -0500

> 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.

    > 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.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 8 Dec 2020 17:15:38 -0500

On Tue, Dec 8, 2020 at 4:33 PM Michael Richardson <[email-masked]>
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

Alas, I'm equally at a loss to understand what you're asking here, as I
can't make much sense of your question?

> 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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Dec 2020 20:13:58 -0500

> 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.

    > 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

    > illustration), since you shouldn't return http-01 authorizations in Step 1

how are http-01 authorizations involved?
The client asks for dns-01 authorizations.

    > other). So I'm not sure what you mean by "does not demonstrate

I think that I have typoed above! :-)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 9 Dec 2020 14:50:31 -0500

> 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

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.

> 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.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Sat, 12 Dec 2020 03:46:41 +0000

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 <[email-masked]>
Sent: 10 December 2020 03:51
To: Michael Richardson <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; Owen Friel (ofriel) <[email-masked]>; Felipe Gasper <[email-masked]>; [email-masked]
Subject: Re: [Acme] acme subdomains open items

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.

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:

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:

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.

    > 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>").

    > to be able to /newOrder for "sub.example.org<http://sub.example.org>" (as Step 2 in the

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.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Dec 2020 15:42:07 -0500

> the dns-01 challenge is more applicable.

I'm gonna pick on this part only.

An http-01 challenge shows that the client controls the web resource that is named.
It does nothing at all about control of the DNS.   We don't know anything
about the client's control over the DNS, about any other names in the DNS.

When we do a dns-01 challenge for a specific name, we mostly prove exactly
the same thing: that the client can direct traffic to that name to a place
that it could potentially control.
{Well, the presence of CNAMEs (and DNAMEs) blurs this a bit}

If we do a dns-01 challenge for foo.example, then there is an assumption
in the challenge that we control the DNS for foo.example, and therefore
could put any.thing.foo.example into the DNS and control that.

Really, it doesn't quite prove that, it proves that we can update
_acme-challenge.foo.example, and that could be the only thing we
can actually control.

We might want to think about whether the authorization phase for
a subdomain challenge might need to show control over more bits than just that.
For instance, we could demand proof of _acme-challenge.ran.dom.token.foo.example.
Perhaps even that we can insert A or AAAA records at that spot too.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Dec 2020 15:47:17 -0500

> the dns-01 challenge is more applicable.

I think that the draft should apply to dns-01 only.

I don't think that http-01 challenges are meaningful in this context, and may
in fact be risk having one tenant of a multi-tenant domain (e.g. domains like
"wix.com"),  wind up with authorization for many things they shouldn't have.
(yes, for wix.com, this would probably require a second bug somewhere)

    > 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.

I guess I'm also confused by why a client would issue an order for a
sub-domain for a domain it has not received authorization.
Obviously, an attacker might do that, but why wouldn't the order just be rejected?

It seems like the client and server are expected to somehow guess where the
zone cuts are, rather than the client starting with that information in it's
configuration.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 14 Dec 2020 12:13:07 -0500

Responding to part of this.

> Obviously, an attacker might do that, but why wouldn't the order just be

I'm not sure what you mean here, could you explain?

It sounds like you're suggesting that pre-authorization should be the only
flow (that is, newAuthz before newOrder). However, newAuthz is optional
(RFC 8555, Section 7.4.1), as also called out in the draft
(draft-friel-acme-subdomains-03, Section 5.1). However, I suspect I'm
misunderstanding your question?