Should Method 22 (Section 3.2.2.4.22) bind normatively to draft-ietf-acme-dns-persist, or should dns-persist-01 get its own bound method rather than restating requirements inline?
Background
Broadly speaking, the TLS BRs have two approaches for aligning a DCV method with an ACME challenge. The first is a superset approach, where an ACME challenge is a constrained profile of a broader BR method (Method 7 and dns-01). The second is a direct binding, where a BR method points normatively at its specific ACME specification: Sections 3.2.2.4.19, 3.2.2.4.20, and 3.2.2.4.21 each bind to their respective ACME specs and layer on additive requirements (3.2.2.4.21 even pins to a specific draft, draft-ietf-acme-dns-account-label draft 00).
Method 22 is to dns-persist-01 roughly what Method 7 is to ACME dns-01; a broad BR container that does not by itself compel the ACME challenge's specific security features.
The Gap
Because Method 22 defines its requirements inline and does not bind to the draft, full BR compliance guarantees the record-format and persistence mechanics but does not mandate the IETF draft's additional security mechanisms, for example the policy attribute or the client-computed-value protection discussed in issue #64.
Discussion so far
This container-vs-challenge question was debated for dns-01 in issue #660 and the April 9 2026 SCWG minutes. Some members favored defining the ACME method as its own BR method for clarity and to avoid compliance ambiguity; others cautioned the ambiguity is largely theoretical and that a separate method adds overlapping methods and audit/logging complexity. No consensus was reached.
Options
Three paths: (1) bind Method 22 normatively to the draft; (2) create a new bound method (a potential Method 23) for dns-persist-01 and leave Method 22 as-is; or (3) do nothing and keep Method 22 restating the requirements inline, managing alignment through future ballots as needed.
This issue is a discussion kickoff as no consensus exists yet.
Should Method 22 (Section 3.2.2.4.22) bind normatively to draft-ietf-acme-dns-persist, or should
dns-persist-01get its own bound method rather than restating requirements inline?Background
Broadly speaking, the TLS BRs have two approaches for aligning a DCV method with an ACME challenge. The first is a superset approach, where an ACME challenge is a constrained profile of a broader BR method (Method 7 and
dns-01). The second is a direct binding, where a BR method points normatively at its specific ACME specification: Sections 3.2.2.4.19, 3.2.2.4.20, and 3.2.2.4.21 each bind to their respective ACME specs and layer on additive requirements (3.2.2.4.21 even pins to a specific draft, draft-ietf-acme-dns-account-label draft 00).Method 22 is to
dns-persist-01roughly what Method 7 is to ACMEdns-01; a broad BR container that does not by itself compel the ACME challenge's specific security features.The Gap
Because Method 22 defines its requirements inline and does not bind to the draft, full BR compliance guarantees the record-format and persistence mechanics but does not mandate the IETF draft's additional security mechanisms, for example the policy attribute or the client-computed-value protection discussed in issue #64.
Discussion so far
This container-vs-challenge question was debated for
dns-01in issue #660 and the April 9 2026 SCWG minutes. Some members favored defining the ACME method as its own BR method for clarity and to avoid compliance ambiguity; others cautioned the ambiguity is largely theoretical and that a separate method adds overlapping methods and audit/logging complexity. No consensus was reached.Options
Three paths: (1) bind Method 22 normatively to the draft; (2) create a new bound method (a potential Method 23) for
dns-persist-01and leave Method 22 as-is; or (3) do nothing and keep Method 22 restating the requirements inline, managing alignment through future ballots as needed.This issue is a discussion kickoff as no consensus exists yet.