Subject: Re: [Acme] working group call for adoption

From: Aaron Gable <[email-masked]>
Date: Wed, 1 Sep 2021 12:00:34 -0700

Substantive comments:

Reading through the history of this document, I see that it started out as
simply specifying server behavior to allow particular kinds of
authorization re-use, and has now grown to an API extension that adds new
fields to various request and response objects. My comments here may seem
like circling back to square one, and for that I apologize. Fresh eyes, and
all that.

Overall, this document reads to me as "RFC 8555 didn't handle wildcards
well; this is essentially how wildcard should have been specified in the
first place". I certainly agree with that stance -- in hindsight, it should
have been possible to do wildcard preauthorization (e.g. by setting a
"wildcard" boolean flag in the preauthorization request). It is unfortunate
that the wording of RFC 8555 seems to preclude simply extending the
existing wildcard mechanism.

That said, it is not clear to me that this draft enables truly novel
behavior. I believe that the desired result -- authorization for a single
parent domain, but issuance only for specific subdomains -- is possible
using current mechanisms:
1) Create a NewOrder for *.example.com
2) Complete the necessary challenge to prove control over example.com
3) Don't bother finalizing the order
4) Create a NewOrder for foo.example.com
5) The ACME Server notices the wildcard authorization for example.com,
attaches that to the new order, and sets the order's state to "valid"
6) Finalize the order, receive a certificate for foo.example.com

Yes, this is messy. It's absolutely just using the newOrder flow as an
end-run around the fact that you can't use newAuthz to generate wildcard
authorizations. But I believe it is fully possible today, with no
extensions or modifications to the ACME protocol. The only changes
necessary to enable this flow would be in internal server policy, creating
a willingness to re-use pre-existing wildcard authorizations with orders
for specific subdomains.

I freely admit that I am less familiar with the RFC process than many here,
so the following proposal may be completely infeasible. But would it be
possible for this draft to effectively become "let's extend newAuthz
requests with a wildcard field"? Then the pre-authorization flow outlined
in the current draft could be used rather than the hack "create but don't
finalize an order" flow I outlined above. Or would the act of contradicting
8555's restrictions on the wildcard field be too big of an issue?

Minor comments:

* In Section 2 Terminology, it would be good to make clear that the CA/BF
BRs are constantly changing, and that the definitions copied into this
document are from a particular version (in the current draft, v1.7.1).
* In the same section, several of these definitions have been updated since
v1.7.1, including ADN now being defined in terms of FQDN rather than in
terms of Domain Names.
* Section 3, Step 4 references "the specified challenge", while none of the
preceding steps identify where that challenge comes from (the authorization
object). Obviously this is not a major comment, as this section is not
normative, but it may cause some confusion for readers less familiar with
ACME.
* In Section 3, the references to various sections of RFC 8555 have
inconsistent capitalization, and one ("Sections 8.3") is pluralized.
* In the HTMLized version of the draft, those section references attempt to
link to sections of this document, rather than linking to RFC 8555.
* The reference to Section 7.1.4 spells out un-capitalized "fully qualified
domain name", while the capitalized version of that term is defined in
Section 2.
* It's not clear to me that Section 4.1 is necessary at all: as the draft
states in Section 7.1, different ACME servers (especially those operating
outside of the CA/BF BRs) may have different server policies. The current
restriction that DNS-01 MUST be used for wildcard validation comes from the
BRs, not from 8555, so it seems inconsistent to mandate DNS-01 in this
document.
* If it is retained, then it seems better to define Section 4.1 in terms of
negatives: challenges HTTP-01 and TLS-ALPN-01 MUST NOT be used. This leaves
the door open for future challenge types which have equivalent security
properties to DNS-01 to be used for this case.
* Finally, in Appendix A, the CA/BF BRs no longer allow Agreed-Upon Change
to Website validations for Wildcard Domain Names.

Thanks,
Aaron

On Tue, Aug 31, 2021 at 8:37 AM Cooley, Dorothy E <decoole=
[email-masked]> wrote:

> This is a working group call for adoption of:
> draft-friel-acme-subdomains-05.  We have had presentations of this work at
> the past couple of IETF meetings (back to when we still met in person -
> sigh).
>
> Please review the draft and post your comments to the list by Wednesday, 15
> September 2021.
>
> Thanks,
> Deb and Yoav
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Sep 2021 19:44:52 -0400

> attaches that to the new order, and sets the order's state to "valid"

This seems to make the ACME server keep a bunch of state itself (across
multiple HTTPS/TLS connections), while I suspect that most of us would like
the client to be responsible for keeping that authorization around.

Would you agree with this?

    > 8555's restrictions on the wildcard field be too big of an issue?

I think that this is reasonable to me, but I've much less knowledge of the
underlying structures than you :-)

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

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 1 Sep 2021 19:58:33 -0400

> Would you agree with this?

I'm not sure I understand this. Isn't it already the case today that ACME
servers necessarily need to track this state?

It's unclear if you're talking about an abstract goal, which the current
specifications may not achieve, certainly not in terms of those widely
deployed, or if you believe there's a concrete deployment today that is
able to achieve this "stateless" design, that the wildcard work would be
applicable to, and which would be unduly burdened by this. Certainly, for
some of the other use cases (e.g. OV and EV using ACME), this is
unquestionably true that state is managed on the server.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Sep 2021 20:28:48 -0400

> servers necessarily need to track this state?

Yes, but not necessarily across TLS connections.

One connects, gets a challenge, sets it up (DNS or HTTP/S), waits for the
authorization check to complete, and sends an order.

I don't know what letsencrypt does, but my understanding is that I could do
all of this on the same connection, and afterward, aside from the certificate
that I append to a database, there is no other moving parts.

---

From: Aaron Gable <[email-masked]>
Date: Wed, 1 Sep 2021 17:31:17 -0700

> that I append to a database, there is no other moving parts.

I do not believe this is an accurate description of the ACME protocol, and
certainly not of any implementation of it that I'm aware of (but I may be
wrong!).

It is true that one could imagine an ACME server which never performs
authorization re-use. It would not support pre-authorization, as it always
creates new authorizations for every name in each new order. Such a server
would be able to support the extensions to the newOrder endpoint proposed
by this draft, but would not be able to support the extensions to newAuthz
proposed by this draft or proposed by my message above.

That said, even such a server is required to keep state about its
authorizations for arbitrarily long periods of time: the authorizations are
created (including the `wildcard` boolean) when the client requests a
newOrder; they are served when the client requests details about the
authorizations for the order; they are updated when the client fulfills
challenges; and they must be examined by the server when the client
requests to finalize the order. Each of these requests is a
separate HTTP/TLS connection from the client to the server, and they may be
seconds, hours, or even days apart, depending on the `expires` timestamp
that the server populates in the order object.

Aaron

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 1 Sep 2021 22:02:51 -0400

> authorization check to complete, and sends an order.

As Aaron mentioned, I'm not only not aware of implementations that do what
you describe, but I also don't believe this was a design goal/constraint of
ACME to support. Indeed, it explicitly runs counter to the use cases that
were intended to be supported with the design (e.g. external accounts or
additional vetting).

Are you aware of implementations - clients or servers - that behave as you
describe? It would be interesting to learn more about them, and what sort
of use cases they exist to support, since it doesn't seem to fit with the
primary use cases ACME was designed to address.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Mon, 13 Sep 2021 06:24:12 +0000

From: Acme <[email-masked]> On Behalf Of Aaron Gable
Sent: 02 September 2021 08:31
To: Michael Richardson <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; Deb Cooley <[email-masked]>; [email-masked]
Subject: Re: [Acme] working group call for adoption

On Wed, Sep 1, 2021 at 5:28 PM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:
Yes, but not necessarily across TLS connections.

I do not believe this is an accurate description of the ACME protocol, and certainly not of any implementation of it that I'm aware of (but I may be wrong!).

It is true that one could imagine an ACME server which never performs authorization re-use. It would not support pre-authorization, as it always creates new authorizations for every name in each new order. Such a server would be able to support the extensions to the newOrder endpoint proposed by this draft, but would not be able to support the extensions to newAuthz proposed by this draft or proposed by my message above.

That said, even such a server is required to keep state about its authorizations for arbitrarily long periods of time: the authorizations are created (including the `wildcard` boolean) when the client requests a newOrder; they are served when the client requests details about the authorizations for the order; they are updated when the client fulfills challenges; and they must be examined by the server when the client requests to finalize the order. Each of these requests is a separate HTTP/TLS connection from the client to the server, and they may be seconds, hours, or even days apart, depending on the `expires` timestamp that the server populates in the order object.

Aaron
[ofriel] Thanks for the all the comments Aaron.

In my mind, the newAuthz proposal in this draft is the more useful and most likely to be implemented approach vs. the extension to newOrder. Consider an RA that wants to get device certs for thousands of devices e.g. foo.type-a-sensors.example.org and bar.type-b-sensors.example.org, The RA would likely do a preAuthz for the domains it owns (e.g. example.org) rather than wait for a device to send an enrol request for a specific identifier (e.g. foo.type-a-sensors.example.org) and the RA then send a newOrder containing “identifiers”: [ {“value”: “foo.type-a-sensors.example.org”, “domainNamespace”:“example.org”} ]. I think this would also make the RA code simpler.

So on balance, I do not think having the “domainNamespace”: “<FQDN>” extension to the newOrder would likely be used much, and am fine with dropping that. This use case did come up in discussions no the mailer over the past year, but simplifying this and removing that newOrder extension is OK. It would also avoid adding this complexity to both RA and ACME server code.

CA/B guidelines states the following in “3.2.2.4 Validation of Domain Authorization or Control” for multiple methods (including DNS):

“Note: Once the FQDN has been validated using this method, the CA MAY also issue
Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN.
This method is suitable for validating Wildcard Domain Names.”

meaning that this covers both the wildcard cert and any subdomain certs in the full domain namespace under that FQDN.

Is there any value in explicitly distinguishing between an authorization for a wildcard vs. an authorization for an entire domain namespace? An RFC8555 wildcard authorization for example.org only allows the *.example.org cert to be issued. Whereas, what we have proposed is that a domainNamespace authorization for example.org enables a cert with any identifier in the entire subordinate domain namespace to be issued. e.g. foo.type-a-sensors.example.org and bar.type-b-sensors.example.org. For sure, for the device cert enrolment and RA use cases we have in mind, the device and RA most definitely do not want a wildcard cert, they want a unique cert per device.

Assuming there is value in this, then the proposed changes to the APIs and objects are actually pretty minimal:

domainNamespace bool in authz object
domainNamespace bool in newAuthz request
domainNamespace bool in directory metadata to advertise the server supports this
domainNamespace string (an FQDN) in newOrder request (which I think we don’t really need, the pre-authorization workflow seems the really useful one here)

Cheers,
Owen

---

From: Aaron Gable <[email-masked]>
Date: Mon, 13 Sep 2021 09:01:53 -0700

On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) <[email-masked]>
wrote:

>
>
> Consider an RA that wants to get device certs for thousands of devices
> e.g. foo.type-a-sensors.example.org and bar.type-b-sensors.example.org,
> The RA would likely do a preAuthz for the domains it owns (e.g.
> example.org) rather than wait for a device to send an enrol request for a
> specific identifier (e.g. foo.type-a-sensors.example.org) and the RA then
> send a newOrder containing “identifiers”: [ {“value”: “
> foo.type-a-sensors.example.org”, “domainNamespace”:“example.org”} ].
>

The point of much of my original message is that this flow is already
possible today (modulo server policy). Instead of doing a preAuthz for
example.org, the subscriber would do a newOrder for *.example.org. The rest
of the process would be identical.

Again, I'm new here and so I'm not sure what criteria we look for when
considering new standards. Maybe a standard that provides a clear,
intuitive alternative to something already possible but kinda hacky is a
good thing; maybe it isn't. That's where my knowledge ends. I'm just trying
to make sure we understand that this behavior is technically possible today.

On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) <[email-masked]>
wrote:

>
> CA/B guidelines states the following in “3.2.2.4 Validation of Domain
> Authorization or Control” for multiple methods (including DNS)...
>

I'm not totally sure which part of my message this is responding to. Just
in case this was responding to my very last bullet point: yes, the BRs
allow multiple methods (including DNS validation) to be used for
subdomains. But they no longer allow Agreed-Upon Change To Website to be
used for subdomains, which means Appendix A needs to be updated.

On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) <[email-masked]>
wrote:

An RFC8555 wildcard authorization for example.org only allows the *.
> example.org cert to be issued.
>

I don't think this is true. The relevant pieces of languages are, as far as
I can tell:

Section 7.1.4:
"This field MUST be present and true for authorizations created as a result
of a newOrder request containing a DNS identifier with a value that was a
wildcard domain name.  For other authorizations, it MUST be absent."
"Wildcard domain names (with "*" as the first label) MUST NOT be included
in authorization objects.  If an authorization object conveys authorization
for the base domain of a newOrder DNS identifier containing a wildcard
domain name, then the optional authorizations "wildcard" field MUST be
present with a value of true."

So an Authorization object can only have the "wildcard" field set if it was
created as the result of a newOrder request for a wildcard domain name, and
the "wildcard" field must be set if the Authorization object conveys
authorization for the base domain of a wildcard domain name.

This says nothing about whether or not that Authorization object also
conveys authorization for other things (such as all subdomains of that base
domain), and says nothing about whether or not that Authorization object
can be re-used for orders other than the one that created it.

Thanks,
Aaron

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 15 Sep 2021 06:46:18 +0000

From: Aaron Gable <[email-masked]>
Sent: 14 September 2021 00:02
To: Owen Friel (ofriel) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Ryan Sleevi <[email-masked]>; Deb Cooley <[email-masked]>; [email-masked]
Subject: Re: [Acme] working group call for adoption

On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) <[email-masked]<mailto:[email-masked]>> wrote:

Consider an RA that wants to get device certs for thousands of devices e.g. foo.type-a-sensors.example.org<http://foo.type-a-sensors.example.org> and bar.type-b-sensors.example.org<http://bar.type-b-sensors.example.org>, The RA would likely do a preAuthz for the domains it owns (e.g. example.org<http://example.org>) rather than wait for a device to send an enrol request for a specific identifier (e.g. foo.type-a-sensors.example.org<http://foo.type-a-sensors.example.org>) and the RA then send a newOrder containing “identifiers”: [ {“value”: “foo.type-a-sensors.example.org<http://foo.type-a-sensors.example.org>”, “domainNamespace”:“example.org<http://example.org>”} ].

The point of much of my original message is that this flow is already possible today (modulo server policy). Instead of doing a preAuthz for example.org<http://example.org>, the subscriber would do a newOrder for *.example.org<http://example.org>. The rest of the process would be identical.

[ofriel] It did come up at the last face-to-face meet IETF106 that the ACME server and authorization objects should explicitly differentiation between authorization for wildcard certs vs. authorization for the full domain namespace.

It was EKR that made that point and asked for this ‘special indicator’: https://datatracker.ietf.org/meeting/106/materials/minutes-106-acme-00. This was the genesis for adding the “domainNamespace” boolean to the authz object (which was called “basedomain” in draft-01).

Again, I'm new here and so I'm not sure what criteria we look for when considering new standards. Maybe a standard that provides a clear, intuitive alternative to something already possible but kinda hacky is a good thing; maybe it isn't. That's where my knowledge ends. I'm just trying to make sure we understand that this behavior is technically possible today.

[ofriel] In general, its better to have the standard clear and explicit and not have implementers having to scratch their heads and jump through hoops to force the behaviour they want.

On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) <[email-masked]<mailto:[email-masked]>> wrote:

CA/B guidelines states the following in “3.2.2.4 Validation of Domain Authorization or Control” for multiple methods (including DNS)...

I'm not totally sure which part of my message this is responding to. Just in case this was responding to my very last bullet point: yes, the BRs allow multiple methods (including DNS validation) to be used for subdomains. But they no longer allow Agreed-Upon Change To Website to be used for subdomains, which means Appendix A needs to be updated.

[ofriel] The point I was attempting to make here, along with the assumption in my email that there is “value in explicitly distinguishing between an authorization for a wildcard vs. an authorization for an entire domain namespace” is that while CA/B policy allows that proof of domain control to be used for issuance of both wildcard and certs with subordinate identifiers in the namespace, this draft defines how an ACME servers can disambiguate between the two. This was the EKR ask at IETF106.

On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) <[email-masked]<mailto:[email-masked]>> wrote:

An RFC8555 wildcard authorization for example.org<http://example.org> only allows the *.example.org<http://example.org> cert to be issued.

I don't think this is true. The relevant pieces of languages are, as far as I can tell:

Section 7.1.4:
"This field MUST be present and true for authorizations created as a result of a newOrder request containing a DNS identifier with a value that was a wildcard domain name.  For other authorizations, it MUST be absent."
"Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects.  If an authorization object conveys authorization for the base domain of a newOrder DNS identifier containing a wildcard domain name, then the optional authorizations "wildcard" field MUST be present with a value of true."

So an Authorization object can only have the "wildcard" field set if it was created as the result of a newOrder request for a wildcard domain name, and the "wildcard" field must be set if the Authorization object conveys authorization for the base domain of a wildcard domain name.

This says nothing about whether or not that Authorization object also conveys authorization for other things (such as all subdomains of that base domain), and says nothing about whether or not that Authorization object can be re-used for orders other than the one that created it.

[ofriel] On rereading, I believe your interpretation is correct, and ACME handling of wildcards is not that restrictive, although the text does not make it implicit, its implicit and a bit ambiguous. This is similar to some of the reasoning behind this draft in the first, as we have clarified that ‘ACME does not mandate that the "identifier" in a newOrder request  matches the "identifier" in "authorization" objects’

The summary for what this draft is trying to accomplish is:

- explicitly handle and differentiate between authorizations for identifiers in subordinate domain name spaces vs. wildcard certs
- clarify how subordinate domain name spaces works for pre-authorization (which is not currently allowed for wildcards)
- I am good with dropping the proposed specification of the top level domain name space that a client controls when sending in a newOrder request for a subordinate identifier, as I believe that the pre-authz flow is the really useful one.

Its probably also a good idea to clarify the wildcard behaviour, as its not entirely clear. Implementor have to define behaviour based on what is not stated vs. what is explicitly stated.

Thanks,
Aaron