Re: [Acme] scope in dns-account-01 and dns-02 challenge

[Ilari Liusvaara <[e-mail]>]

On Thu, Mar 21, 2024 at 11:44:22AM -0700, Jacob Hoffman-Andrews wrote:
> Ilari, you've posted some useful extrapolations on how domain scopes could
> work. I'm proposing to get rid of domain scopes. :D To get us on the same
> page, would you mind posting some of the specific use cases you're
> envisioning where domain scopes would be used in an ACME environment? My
> existing belief is that domain scopes are only useful when validation is
> non-automated, but I could be wrong here.

Well, in what I proposed, if ACME server (CA) does not support domain
scope, it does not need to do anything. And ACME client that does not
support domain scopes only has to ignore the parameter (not error on
it).

As for usecases, I am not really coming up with those, due to the
folloiwng apparent conflict:

- Domain scopes seem only useful for larger systems.
- Larger systems likely want to apply access controls to different
  parts of the tree, which is not compatible with domain scopes.

However, stuff like this is well within configurability for an automated
client. Looking at configuration for stuff I maintain, there are the
following pieces of configuration about DNS validation (the list is
exhaustive for stuff outside DNS itself):

- The root of DNS zone for validation.
- Name of TSIG/SHA256 key to use for DNS updates.
- TSIG/SHA256 key for DNS updates (in a separate file for security
  reasons).

Having information about domain roots and using those seems feasible.


And actually looking at RFC9444, it looks like it actually has the
required controls for the client (as it should), so presumably rules
(that were proposed earlier) like:

1) If subdomainAuthAllowed, then it is domain
2) Otherwise, if wildcard, then it is wildcard.
3) Otherwise, It is host.

Would seem to work. Both clients and servers that don't want to support
the subdomain stuff can just completely omit the code.




-Ilari