Would it be illegal to server probe both scope and pass if there is intended token?
On 2024년 3월 19일 오전 8시 3분 7초 GMT+09:00, Jacob Hoffman-Andrews <jsha=40letsencrypt....@dmarc.ietf.org> wrote: >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
