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 protected]> On Behalf Of Jacob Hoffman-Andrews Sent: 05 August 2020 07:53 To: Felipe Gasper <[email protected]> Cc: [email protected] 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.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
