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]> 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]" 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/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]" 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/CAEmnErd5Fo35uAOEgr2aQkk1M%2B%3DTrXFehSG9X-QHoCcskv1hbg%40mail.gmail.com.
