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.
