Policy constraints as a variant

[moonshiner]

(from Erik)

Within ACME, challenge tokens exist as only one part of the validation
process. They act as an explicit "allow this particular name to be
issued this particular cert based on a CSR". There is also another
safeguard, however, which is the CAA record. That acts as a
policy-based constraint.

As we are generalizing the challenges, it may be worth considering
generalizing the policy-based constraints. For example, in an
enterprise environment "example.com" may wish to limit the use
of _foo-challenge under their domain so that bar.quux.example.com can't
put in "_foo-challenge.bar.quux.example.com".(More concretely,
example.com may wish to limit the CDNs and/or SaaS providers that can
be used within their domain.)

This is almost certainly substantial scope creep for this draft, but
without it domain admins may be unable to apply policies or manage the
sort of risks managed with CAA records.

This might be as simple as allowing the definition
of _foo-constraint.example.com as a TXT record, with whoever
defines _foo-challenge also defining the format of _foo-constraint. As
part of validating _foo-challenge.bar.quux.example.com, validators
should look for
_foo-constraint.example.com and _foo-constraint.quux.example.com
and _foo-constraint.bar.quux.example.com and implementing their
constraints when present.

[enygren]

I touch on this briefly in PR #89 (mostly giving an example) but this may be better as a separate draft, either in dnsop or in dbound2 (if chartered).

In thinking about this, there's huge overlap between this issue (being able to apply policy constraints to a domain) and the goals of DBOUND and the PSL. CAA is just one specific use-case of this (and one that has some sharp edges and brokenness so isn't a terribly good example).

It may be that this should get moved into the "future" bucket unless others disagree?