Thanks, authors, for the updates in
https://datatracker.ietf.org/doc/html/draft-ietf-acme-scoped-dns-challenges-00
.
Adding a "scope" (host, wildcard, or subdomain) to the DNS record name is
great. Reading the draft, I think it doesn't specify how the scope for a
given challenge is decided and communicated. Three ideas:
1. Server picks, and tells the client.
The challenge object contains a "scope" field. The client verifies that the
indicated scope is one of "host", "wildcard", or "subdomain", and is less
than the maximal scope the client is willing to validate for. For instance,
a client might be configured to only accept "host" scope.
2. Client picks.
When the client POSTs to the challenge URL, instead of sending the empty
object {}, it sends {"scope": "host"}, {"scope": "wildcard"}, or {"scope":
"domain"}. The server verifies that the request scope is sufficient for the
authorization object (i.e. "wildcard" or above for an authorization object
that can be used to issue for a wildcard name), then performs the
validation.
3. Server offers options via challenge types
We explode out the challenge types from two to six:
dns-host-02
dns-wildcard-02
dns-domain-02
dns-account-host-01
dns-account-wildcard-01
dns-account-domain-01
The server populates the authorization object with only those challenge
types that are acceptable. For instance, if the authorization object can be
used to issue for a wildcard name, the server would not offer dns-host-02
or dns-account-host-01.
I like this option the best because it provides cleaner separation, and
uses the design of ACME nicely: servers offer appropriate challenges, and
clients pick the challenge that works best for them. Also it allows for
clean implementation in the BRs: they could specify by name which challenge
types are allowed to issue for wildcards.
Of course, it feels messy to define so many challenge types. Perhaps we
could eliminate the dns-02 family? The idea being that clients and servers
that wish to adopt the modern best practices from
https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/,
they can also adopt the account-scoping features of the dns-account-01
family, which are not burdensome.
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
