Hi Aaron-san, Thank you for the clear and helpful response.
I understand your point that the main intent of RFC 8657 Section 5.3 is to avoid inconsistent enforcement within the same CA (e.g., one system ignoring “accounturi” / “validationmethods” while another respects them). I also appreciate the clarification that, for BR 3.2.2.4.22, the normative reference is primarily to RFC 8657 Section 3 (how the CA determines the expected accounturi strings for DNS records), and that much of Section 5.3 is not directly relevant to that BR method. It is also helpful to hear that it is always acceptable to not issue a certificate, and therefore it is fine for a given issuance system to reject Persistent TXT Records that contain an accounturi that only a different system would have authorized. Thanks again for your guidance. Best regards, ONO Fumiaki / 大野 文彰 (Japanese name order: family name first, in uppercase) SECOM Trust Systems CO., LTD. From: 'Aaron Gable' via [email protected] <[email protected]> Sent: Friday, February 20, 2026 8:33 AM To: 大野 文彰 <[email protected]> Cc: [email protected] Subject: Re: Understanding accounturi handling across manual and ACME issuance (RFC 8657 Section 5.3) I believe your understanding is correct. The key point that RFC 8657 Section 5.3 is trying to get across is that it is unacceptable for one CA system to ignore the "accounturi" and "validationmethods" parameters, while another system at the same CA respects them. This would result in them being inconsistently enforced, which would be a violation of the user's security expectations. That said, most of what RFC 8657 Section 5.3 is talking about here is not relevant to BRs method 3.2.2.4.22 DNS TXT Record with Persistent Value. The only part of RFC 8657 normatively referenced by that validation method is Section 3, which describes how a CA should determine the accounturi strings it expects to see in DNS records. It is always acceptable to not issue a certificate. If some of your systems reject certain Persistent TXT Records because they happen to contain an accounturi that only a different one of your systems would have recognized... that's just fine. Aaron On Thu, Feb 19, 2026 at 10:25 AM 大野 文彰 <[email protected]<mailto:[email protected]>> wrote: Hello, Recently, we have been asked similar questions by multiple CAs regarding how accounturi should be handled when introducing ACME alongside existing issuance systems. This prompted us to re-examine the interpretation of RFC 8657<https://www.rfc-editor.org/rfc/rfc8657> and BR 3.2.2.4.22<https://github.com/cabforum/servercert/blob/main/docs/BR.md#322422-dns-txt-record-with-persistent-value> from a broader ecosystem perspective. I would like to ask for feedback on our understanding regarding the use of Persistent DCV (RFC 8657 / BR 3.2.2.4.22), specifically about accounturi handling when a CA operates multiple issuance systems. We are considering the following model and would appreciate feedback on whether this interpretation aligns with the intent of RFC 8657 Section 5.3. Background * The CA uses Persistent DCV based on RFC 8657. * accounturi values identify CA-managed account objects. * The CA may operate multiple issuance systems (manual issuance, non-ACME automated issuance, and ACME). Our understanding is that RFC 8657 Section 5.3 requires issuance systems to “recognize the same parameters” when multiple issuance paths exist, while still allowing protocol-specific authorization decisions by the CA. Case A: Manual issuance followed by ACME introduction Phase 1 * The CA issues accounturi values from a unified account management system (which is also intended to support ACME in the future). * These accounturi values are initially authorized only for manual issuance. * ACME issuance is not yet available. Phase 2 * The CA introduces ACME. * accounturi values are categorized by authorization scope: * Manual-only accounturi: accepted only by manual issuance and explicitly rejected by ACME issuance. * ACME accounturi: accepted only by ACME issuance and rejected by manual issuance. * All issuance systems recognize and parse all accounturi values consistently, but enforce protocol-specific authorization. Case B: Non-ACME automated issuance and ACME Phase 1 * The CA operates a non-ACME automated issuance system. * accounturi values are issued and authorized only for this non-ACME automated issuance. Phase 2 * The CA introduces ACME. * Two distinct types of accounturi exist: * accounturi (1): authorized only for non-ACME automated issuance. * accounturi (2): authorized only for ACME issuance. * As in Case A, all issuance systems recognize all accounturi values, but authorization is scoped by issuance protocol. Key clarification Although accounturi values may be issued by an ACME-related account management system, authorization for ACME issuance is explicitly controlled. In particular, manual-only accounturi values are intentionally rejected by ACME issuance, even though they are recognized. Our understanding Our understanding is that both cases satisfy RFC 8657 Section 5.3, because accounturi values are consistently recognized across issuance systems and authorization decisions are enforced per issuance protocol without ignoring or reinterpreting accounturi semantics. We would appreciate any feedback on whether there are concerns or overlooked issues with this interpretation from a policy or root store perspective. Thank you for your time and guidance. Best regards, ONO Fumiaki / 大野 文彰 (Japanese name order: family name first, in uppercase) SECOM Trust Systems CO., LTD. -- You received this message because you are subscribed to the Google Groups "[email protected]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/TY7P286MB76513F6986ABD53D488FCA3BAE6BA%40TY7P286MB7651.JPNP286.PROD.OUTLOOK.COM<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/TY7P286MB76513F6986ABD53D488FCA3BAE6BA%40TY7P286MB7651.JPNP286.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "[email protected]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErd5Fo35uAOEgr2aQkk1M%2B%3DTrXFehSG9X-QHoCcskv1hbg%40mail.gmail.com<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErd5Fo35uAOEgr2aQkk1M%2B%3DTrXFehSG9X-QHoCcskv1hbg%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/OSOP286MB7648BD9CCD89345E7F1BD927AE74A%40OSOP286MB7648.JPNP286.PROD.OUTLOOK.COM.
