Subject: Re: [Acme] ACME subdomains

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 2 Sep 2020 09:40:23 +0000

Thanks Felipe, Jacob, we had not really considered the use case where the server would offer challenges for both foo.bar.example.org<http://foo.bar.example.com> and example.org<http://example.com> and the client could choose which to fulfil.

We assumed (maybe naively) that the server would only offer the Base Domain Name challenge (using the CA/B Baseline defn. of the Base Domain Name), and also wanted to minimise changes to the protocol and JSON objects.

For flexibility, I guess if the client wants foo.bar.example.org<http://foo.bar.example.com> the protocol should also allow server choice of offering challenges for (1) both foo.bar.example.org<http://foo.bar.example.com> and  example.com<http://example.com> (2) only the requested identifier foo.bar.example.com<http://foo.bar.example.com> or (3) only the parent domain example.com<http://example.com>.

I was talking through this with Richard, and there are a few choices for how to enhance the authorizations object to allow this. If the server only wants to offer one challenge, then that’s straight forward. It includes whatever identifier it picks (subdomain or parent) in the authorization object. If it wants to include both, here are a few options:

Both option 1. Your suggestion. I think we need new challenges types for the parent for each of the supported challenge types e.g. http-parent-01 and dns-parent-01.

~~~
   {
     "status": "pending",
     "expires": "2015-03-01T14:09:07.99Z",

     "identifier": {
       "type": "dns",
       "value": "foo.bar.example.org"
     },

     "challenges": [
       {
         "url": "https://example.com/acme/chall/prV_B7yEyA4",
         "type": "http-01",
         "status": "pending",
         "token": "DGyRejmCefe7v4NfDGDKfA",
       },
       {
         "url": "https://example.com/acme/chall/prV_B7yEyA4",
         "type": "http-parent-01",
         "parent-identifier":"example.org",
         "status": "pending",
         "token": "DGyRejmCefe7v4NfDGDKfA",
       },
       {
         "url": "https://example.com/acme/chall/prV_B7yEyA4",
         "type": "dns-parent-01",
         "parent-identifier":"example.org",
         "status": "pending",
         "token": "DGyRejmCefe7v4NfDGDKfA",
       }
     ],
   }
~~~

Both option 2. The challenge for the parent domain is of a new type that contains a set of nested challenges of existing types.

~~~
   {
     "status": "pending",
     "expires": "2015-03-01T14:09:07.99Z",

     "identifier": {
       "type": "dns",
       "value": "foo.bar.example.org"
     },

     "challenges": [
       {
         "url": "https://example.com/acme/chall/prV_B7yEyA4",
         "type": "http-01",
         "status": "pending",
         "token": "DGyRejmCefe7v4NfDGDKfA",
       },
       {
         "url": "https://example.com/acme/chall/PAniVnsZcis",
         "type": related-identifier",
         "status": "pending",
          "related-identifier":"example.org",
          "challenges":[
                   {
               "url": "https://example.com/acme/chall/prV_B7yEyA4",
               "type": "http-01",
               "status": "pending",
               "token": "DGyRejmCefe7v4NfDGDKfA",
               },
               {
               "url": "https://example.com/acme/chall/prV_B7yEyA4",
               "type": "dns-01",
               "status": "pending",
               "token": "DGyRejmCefe7v4NfDGDKfA",
             },
         ]
       }
     ]
   }
~~~

Both option 3. A new challenge type that points to another new authorization object. This can be standard authorization obejct that includes http-01, dns-01 challenges for the parent. It may make sense to also include the parent domain in this new challenge, even though it will be in the 2nd authorization.

~~~
   {
     "status": "pending",
     "expires": "2015-03-01T14:09:07.99Z",

     "identifier": {
       "type": "dns",
       "value": "foo.bar.example.org"
     },

     "challenges": [
       {
         "url": "https://example.com/acme/chall/prV_B7yEyA4",
         "type": "http-01",
         "status": "valid",
         "token": "DGyRejmCefe7v4NfDGDKfA",
         "validated": "2014-12-01T12:05:58.16Z"
       },
       {
         "url": "https://example.com/acme/chall/PAniVnsZcis",
         "type": related-identifier",
         "related-identifier":"example.org",
         "related-authorization":"uri"
         "status": "pending"
       }
     ],
   }
~~~

Of all the above, option 3 arguably keeps the client implementation and logic as close to base ACME as possible.

From: Acme <[email-masked]> On Behalf Of Jacob Hoffman-Andrews
Sent: 05 August 2020 07:53
To: Felipe Gasper <[email-masked]>
Cc: [email-masked]
Subject: Re: [Acme] ACME subdomains

I haven't followed the "ACME for subdomains" conversation closely, but the base semantics of ACME are designed such that they can express "all of" semantics AND "one of" semantics. For a given Order, a client has to fulfil all the Authorizations; for a given Authorization, a client has to fulfil one of the Challenges.

To take advantage of this, you would need to define a new challenge type that expresses validating a parent domain. For instance "dns-parent-01." It would contain the name of the parent domain as a field.

If a server has the policy that validating control of either foo.bar.example.com<http://foo.bar.example.com> or example.com<http://example.com> is sufficient to issue for foo.bar.example.com<http://foo.bar.example.com>, it would respond to newOrder requests for foo.bar.example.com<http://foo.bar.example.com> by creating an Order with one Authorization (for foo.bar.example.com<http://foo.bar.example.com>), and that Order would have two Challenges: "dns-01" and "dns-parent-01" (with a parent domain of "example.com<http://example.com>"). The client could then choose which challenge to attempt.

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 2 Sep 2020 11:07:47 -0400

There’s a lot of mixing of example.org and example.com here, in ways I’m
having trouble making sense of. I just wanted to confirm those were typos,
since we have recently seen some confusion around this space.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Thu, 3 Sep 2020 03:10:08 +0000

I followed the patterns used in RFC8555 which consistently uses example.com as the ACME server base domain and example.org as the client certificate identifier base domain, but yes Ryan I did find this a source of confusion too when reading ACME.

For clarity, I replaced all example.com with acmeserver.com, and left all the client identifiers as example.org. I also replaced all the random values in the tokens and URIs so that duplicate random values (i.e. duplicate URIs or tokens) are not used within an option example, as this could have caused confusion too.

~~~
   {
     "status": "pending",

     "identifier": {
       "type": "dns",

     "challenges": [
       {
         "url": "https://acmeserver.com/acme/chall/prV_B7yEyA4",
         "type": "http-01",
         "status": "pending",
         "token": "DGyRejmCefe7v4NfDGDKfA",
       },
       {
         "url": "https://acmeserver.com/acme/chall/NvGuSDAgel",
         "type": "http-parent-01",
         "parent-identifier":"example.org",
         "status": "pending",
         "token": "4ri0VOyfYe",
       },
       {
         "url": "https://acmeserver.com/acme/chall/Nd0E0RmHYe",
         "type": "dns-parent-01",
         "parent-identifier":"example.org",
         "status": "pending",
         "token": "S9nQjcWrSI",
       }
     ],
   }
~~~

~~~
   {
     "status": "pending",

     "identifier": {
       "type": "dns",

     "challenges": [
       {
         "url": "https://acmeserver.com/acme/chall/9eDK8EeM8R",
         "type": "http-01",
         "status": "pending",
         "token": "DGyRejmCefe7v4NfDGDKfA",
       },
       {
         "url": "https://acmeserver.com/acme/chall/PAniVnsZcis",
         "type": related-identifier",
         "status": "pending",
          "related-identifier":"example.org",
          "challenges":[
                   {
               "url": "https://acmeserver.com/acme/chall/NYV9zTtOBT",
               "type": "http-01",
               "status": "pending",
               "token": "q1XCKRP2DX",
               },
               {
               "url": "https://acmeserver.com/acme/chall/25OE1ZoicK",
               "type": "dns-01",
               "status": "pending",
               "token": "bLfEMqhoVp",
             },
         ]
       }
     ]
   }
~~~

~~~
   {
     "status": "pending",

     "identifier": {
       "type": "dns",

     "challenges": [
       {
         "url": "https://acmeserver.com/acme/chall/RW9UppaYs0",
         "type": "http-01",
         "status": "pending",
         "token": "DGyRejmCefe7v4NfDGDKfA",
       },
       {
         "url": "https://acmeserver.com/acme/chall/PAniVnsZcis",
         "type": related-identifier",
         "related-identifier":"example.org",
         "related-authorization":" https://example.com/acme/authz/r4HqLzrSrpI"
         "status": "pending"
       }
     ],
   }
~~~

And for option 3, the related-authorization points to the authorization object for the parent domain e.g. POST-as-GET to the “related-authorization” https://example.com/acme/authz/r4HqLzrSrpI :

~~~
   {
     "status": "pending",

     "identifier": {
       "type": "dns",
       "value": " example.org"
     },

     "challenges": [
       {
         "url": "https://acmeserver.com/acme/chall/prV_B7yEyA4",
         "type": "http-01",
         "status": "pending",
         "token": "DGyRejmCefe7v4NfDGDKfA",
       },
       {
         "url": "https://acmeserver.com/acme/chall/Nd0E0RmHYe",
         "type": "dns-01",
         "status": "pending",
         "token": "S9nQjcWrSI",
       }
     ],
   }
~~~

From: Ryan Sleevi <[email-masked]>
Sent: 02 September 2020 23:08
To: Owen Friel (ofriel) <[email-masked]>
Cc: Felipe Gasper <[email-masked]>; Jacob Hoffman-Andrews <[email-masked]>; [email-masked]
Subject: Re: [Acme] ACME subdomains

There’s a lot of mixing of example.org<http://example.org> and example.com<http://example.com> here, in ways I’m having trouble making sense of. I just wanted to confirm those were typos, since we have recently seen some confusion around this space.

---

From: "Manger, James" <[email-masked]>
Date: Thu, 3 Sep 2020 04:51:58 +0000

> For clarity, I replaced all example.com with acmeserver.com, and left all the client identifiers as example.org.

https://tools.ietf.org/html/draft-friel-acme-subdomains-02 and https://github.com/upros/acme-subdomains/blob/master/draft-friel-acme-subdomains.md don’t seem to follow RFC 8555’s convention at all, which could be the confusion.

Trampling on another arbitrary domain name – acmeserver.com – is worse; unless you can think of an additional domain name to reserve with an update to RFC 6761 Special-Use Domain Names.

Stick with the RFC 8555 ACME convention. Maybe tweak it to be, say, site.example.org and ca.example.com if that is clearer.
Plus a sentence stating the convention used would help.

--
James Manger

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Sep 2020 13:45:33 +0000

*   I followed the patterns used in RFC8555 which consistently uses example.com as the ACME server base domain and example.org as the client certificate identifier base domain, but yes Ryan I did find this a source of confusion too when reading ACME.

Thanks for the changes.  I am also confused by example.com and example.org.  Someone want to grab acmeserver.org and donate it?

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 3 Sep 2020 11:24:04 -0400

On Thu, Sep 3, 2020 at 9:47 AM Salz, Rich <[email-masked]> wrote:

>
>    - I followed the patterns used in RFC8555 which consistently uses
>    example.com as the ACME server base domain and example.org as the
>    client certificate identifier base domain, but yes Ryan I did find this a
>    source of confusion too when reading ACME.
>
>
>
> Thanks for the changes.  I am also confused by example.com and example.org.
> Someone want to grab acmeserver.org and donate it?
>

That still seems problematic; registrations are fixed lifetimes.

Just use RFC 6761 https://tools.ietf.org/html/rfc6761#section-6.5

Specifically, acmeserver.example

As James points out, the use isn't really consistent with RFC 8555 in the
examples provided, and that's why it bears clarifying. However, my specific
concern was this statement:

"For flexibility, I guess if the client wants foo.bar.example.org the
protocol should also allow server choice of offering challenges for (1)
both foo.bar.example.org and  example.com (2) only the requested identifier
foo.bar.example.com or (3) only the parent domain example.com."

Which is the problematic area. I believe this is "trying" to say that the
options are:

foo.bar.example.org
bar.example.org
example.org

And all permutations/combinations of those.

Whether those go to acmeserver.com or acmeserver.example is irrelevant; the
point of clarification is what challenges can be used for the identifier.