Re: [Acme] ACME subdomains

["Owen Friel (ofriel)" <[e-mail]>]

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.



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://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",
       }
     ],
   }
~~~

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://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",
             },
         ]
       }
     ]
   }
~~~

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://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",
     "expires": "2015-03-01T14:09:07.99Z",

     "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",
       }
     ],
   }
~~~





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


From: Ryan Sleevi <[e-mail]>
Sent: 02 September 2020 23:08
To: Owen Friel (ofriel) <[e-mail]>
Cc: Felipe Gasper <[e-mail]>; Jacob Hoffman-Andrews <[e-mail]>; [e-mail]
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.