Understanding accounturi handling across manual and ACME issuance (RFC 8657 Section 5.3)

[大野 文彰]

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 and BR 3.2.2.4.22 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.

[Aaron Gable]

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

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/TY7P286MB76513F6986ABD53D488FCA3BAE6BA%40TY7P286MB7651.JPNP286.PROD.OUTLOOK.COM.