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 _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
