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 <ryan-i...@sleevi.com>
Sent: 02 September 2020 23:08
To: Owen Friel (ofriel) <ofr...@cisco.com>
Cc: Felipe Gasper <fel...@felipegasper.com>; Jacob Hoffman-Andrews
<j...@letsencrypt.org>; acme@ietf.org
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.
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
