Background/Motivation
The TLS BRs adopted a one-to-many account paradigm for CAA records in Section 4.2.2.1.2 (the Parent Account / Subordinate ACME Account model, effective 2027-03-15).
For Method 22, is a one-to-many accounturi already permitted under the current text, or do the BRs need explicit one-to-many language to align Method 22 with what Section 4.2.2.1.2 already established for CAA?
Evidence that it is already permitted:
This question was posed on a servercert-wg thread. On that thread a few members read the current Method 22 text as already allowing this. Their reasoning: in the BRs, "account" means the Applicant's account with the CA (a customer account), not a single ACME account. Method 22 leans on RFC 8657 Section 3's generic language ("a URI identifying a specific CA account"). The term "account" is never defined in the BRs, so the natural reading is the broader one.
Evidence that explicit language is needed:
Section 4.2.2.1.2 already spells out the one-to-many case for CAA with guardrails: auditable mapping, verified explicit authorization, audit-log retention. Method 22 says nothing comparable, creating an inconsistency.
Proposed Paths:
Path 1: Light clarification (one-to-many is already permitted). Confirm that "account" in Method 22 means the Applicant's CA customer account, which may span multiple ACME accounts. No new guardrails; the existing Method 22 text plus RFC 8657 Section 3's generic URI reference already covers this.
Path 2: Full alignment with Section 4.2.2.1.2 guardrails. Add explicit one-to-many language to Method 22 mirroring the Parent Account / Subordinate ACME Account model in Section 4.2.2.1.2: auditable mapping, verified explicit authorization, audit-log retention.
Path 3: No changes needed.
Background/Motivation
The TLS BRs adopted a one-to-many account paradigm for CAA records in Section 4.2.2.1.2 (the Parent Account / Subordinate ACME Account model, effective 2027-03-15).
For Method 22, is a one-to-many accounturi already permitted under the current text, or do the BRs need explicit one-to-many language to align Method 22 with what Section 4.2.2.1.2 already established for CAA?
Evidence that it is already permitted:
This question was posed on a servercert-wg thread. On that thread a few members read the current Method 22 text as already allowing this. Their reasoning: in the BRs, "account" means the Applicant's account with the CA (a customer account), not a single ACME account. Method 22 leans on RFC 8657 Section 3's generic language ("a URI identifying a specific CA account"). The term "account" is never defined in the BRs, so the natural reading is the broader one.
Evidence that explicit language is needed:
Section 4.2.2.1.2 already spells out the one-to-many case for CAA with guardrails: auditable mapping, verified explicit authorization, audit-log retention. Method 22 says nothing comparable, creating an inconsistency.
Proposed Paths:
Path 1: Light clarification (one-to-many is already permitted). Confirm that "account" in Method 22 means the Applicant's CA customer account, which may span multiple ACME accounts. No new guardrails; the existing Method 22 text plus RFC 8657 Section 3's generic URI reference already covers this.
Path 2: Full alignment with Section 4.2.2.1.2 guardrails. Add explicit one-to-many language to Method 22 mirroring the Parent Account / Subordinate ACME Account model in Section 4.2.2.1.2: auditable mapping, verified explicit authorization, audit-log retention.
Path 3: No changes needed.