Automated Certificate Management Environment (ACME) Identity-Controlled Validation Extension
draft-geng-acme-idp-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Feng Geng , Panyu Wu , 陈鑫 | ||
| Last updated | 2026-05-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-geng-acme-idp-00
Automated Certificate Management Environment Working Group F. Geng
Internet-Draft P. Wu
Intended status: Standards Track Huawei Technologies
Expires: 20 November 2026 X. Chen
TrustAsia
19 May 2026
Automated Certificate Management Environment (ACME) Identity-Controlled
Validation Extension
draft-geng-acme-idp-00
Abstract
This document defines an Identity Control Validation (ICV) framework
for the ACME protocol [RFC8555], introducing a new ACME identifier
type "idp" and a new challenge type "idp-01". The ICV framework
allows ACME servers to delegate trusted Identity Providers (IdPs) to
verify certificate applicants’ control over the claimed identities.
This document also defines an optional X.509 certificate extension,
the Trust-Domain-Restricted Certificate Extension, which explicitly
indicates that certificates issued via the ICV framework are backed
by a specific IdP trust domain and whose trustworthiness depends on
the current status and policies of that IdP, preventing trust leakage
into contexts outside the IdP’s trust domain.
This extension is parallel to Domain Control Validation (DCV)
[RFC8555]; either can independently verify an applicant’s control
over identities/resources and request certificates.
Proof-of-Possession (PoP) [I-D.geng-acme-public-key] serves as an
auxiliary enhancement framework. Based on this architecture, two
standardized certificate enrollment models are formed: the Domain
Validation model (DCV + optional PoP) and the Identity Validation
model (ICV + optional PoP). This document focuses on the latter.
This document defines three deployment models: the IdP-Operated
Certificate Model, the Intra-PKI Domain Mutual-Trust Model, and the
CA-Integrated IdP Model. It supports multiple authentication
protocols via the extensible idp_method parameter, covering both
device and account identities.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Geng, et al. Expires 20 November 2026 [Page 1]
Internet-Draft ACME PK Challenge May 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Verification Dimensions in ACME . . . . . . . . . . . . . 5
1.2. Review of Prior Work and Scope of This Document . . . . . 5
1.3. Design Principles . . . . . . . . . . . . . . . . . . . . 7
1.4. Solution Overview . . . . . . . . . . . . . . . . . . . . 7
1.5. Relationship to Existing Work . . . . . . . . . . . . . . 8
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 9
3. ICV Framework Architecture . . . . . . . . . . . . . . . . . 10
3.1. Three Validation Dimensions and Three Major Protocol
Frameworks . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Hierarchical Trust Model . . . . . . . . . . . . . . . . 11
3.3. Two Standard Certificate Enrollment Modes . . . . . . . . 12
3.4. Identity Identifier Types and Coverage Scope . . . . . . 13
3.5. Synergy Matrix of ICV and PoP . . . . . . . . . . . . . . 13
4. Deployment Modes . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Mode 1: IdP-Operated Certificate Model . . . . . . . . . 14
4.1.1. Trust Establishment . . . . . . . . . . . . . . . . . 15
4.1.2. ACME-IDP Client . . . . . . . . . . . . . . . . . . . 16
4.1.3. Subsequent Identity Validation . . . . . . . . . . . 17
4.2. Mode 2: PKI Intra-Domain Mutual-Trust Model . . . . . . . 17
Geng, et al. Expires 20 November 2026 [Page 2]
Internet-Draft ACME PK Challenge May 2026
4.3. Mode 3: CA-Integrated IdP Model . . . . . . . . . . . . . 18
4.4. Mode Selection Guidance . . . . . . . . . . . . . . . . . 18
5. ICV Framework Protocol Flow . . . . . . . . . . . . . . . . . 19
5.1. Overall Interaction Model . . . . . . . . . . . . . . . . 19
5.2. ACME-ICV Client Behavior . . . . . . . . . . . . . . . . 21
6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 21
6.1. The "idp-01" Challenge Object . . . . . . . . . . . . . . 21
6.1.1. Trigger Conditions . . . . . . . . . . . . . . . . . 22
6.1.2. Challenge Object Fields . . . . . . . . . . . . . . . 22
6.2. IdP Authentication Methods . . . . . . . . . . . . . . . 23
6.2.1. Account Identity Authentication Methods . . . . . . . 23
6.2.2. Device Identity Authentication Methods . . . . . . . 23
6.3. Format of the "acmeIdpToken" . . . . . . . . . . . . . . 24
6.4. Challenge Response and Server Validation . . . . . . . . 26
6.5. Trust-Domain-Restricted Certificate Extension . . . . . . 27
6.5.1. Extension Definition . . . . . . . . . . . . . . . . 27
6.5.2. Critical Marking Policy . . . . . . . . . . . . . . . 28
6.5.3. Boundary with the RFC 5280 certificatePolicies
Extension . . . . . . . . . . . . . . . . . . . . . . 28
6.5.4. CA Writing Requirements . . . . . . . . . . . . . . . 29
6.6. Error Types . . . . . . . . . . . . . . . . . . . . . . . 29
6.7. IdP Operational Certificate Format and
Interoperability . . . . . . . . . . . . . . . . . . . . 29
6.7.1. Certificate Format Requirements . . . . . . . . . . . 30
6.7.2. Interoperability with Existing IdPs . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7.1. Trust Anchor Levels and Threat Model . . . . . . . . . . 31
7.2. Layered PoP Verification . . . . . . . . . . . . . . . . 31
7.3. Certificate Lifecycle and Authentication Strength . . . . 32
7.4. Timeliness . . . . . . . . . . . . . . . . . . . . . . . 32
7.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.6. Comparison with the SSO/OAuth Security Model . . . . . . 33
7.7. Comparison of Security Models between SSO/OAuth and
idp-01 . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.8. Comparison with Stand-Alone Use of RFC 9447 . . . . . . . 36
7.9. Order Binding . . . . . . . . . . . . . . . . . . . . . . 37
7.10. Relying-Party Validation Logic for Trust-Domain-Restricted
Certificates . . . . . . . . . . . . . . . . . . . . . . 38
7.10.1. Handling of Critical and Non-Critical Extensions . . 39
7.10.2. Relationship with Defense-in-Depth . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
9. Appendix A. Same-Domain Trust — Example of the IdP Operational
Certificate Mode (Mode 1, Stand-Alone ICV + CSR) . . . . 41
9.1. Phase 1: IdP Requests an Operational Certificate . . . . 41
9.2. Phase 2: User Requests an Identity Certificate . . . . . 42
10. Appendix B. Same-Domain Trust — Example of CA-Integrated IdP
Mode (Mode 3) . . . . . . . . . . . . . . . . . . . . . . 42
10.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . 43
Geng, et al. Expires 20 November 2026 [Page 3]
Internet-Draft ACME PK Challenge May 2026
10.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 43
10.3. Scenario Value . . . . . . . . . . . . . . . . . . . . . 44
11. Appendix C. Same-Domain / Cross-Domain Trust — Enterprise PKI
Bridging Scenario (Mode 2) . . . . . . . . . . . . . . . 44
11.1. Scenario 1: Same-Domain Trust . . . . . . . . . . . . . 44
11.2. Scenario 2: Cross-Domain Trust . . . . . . . . . . . . . 45
12. Appendix D. Cross-Domain Trust — E2EE Meeting Certificate
Provisioning (Mode 1 + Mode 2) . . . . . . . . . . . . . 45
12.1. Case 1: Pre-established Root-Certificate Mutual Trust
Between Both Enterprises (Mode 2) . . . . . . . . . . . 46
12.2. Case 2: No Pre-established Root-Certificate Mutual Trust
Between Enterprises — Guest Mode (Mode 1) . . . . . . . 46
13. Appendix E. Cross-Domain Trust — Automated C2PA Certificate
Issuance (Mode 1 / Mode 2 / Mode 3) . . . . . . . . . . . 47
13.1. Requirements Description . . . . . . . . . . . . . . . . 48
13.2. Applicability of the Three Deployment Modes . . . . . . 48
13.3. Deployment Recommendations . . . . . . . . . . . . . . . 48
14. Appendix F. Cross-Domain Trust — Federated Trust Scenarios
(Mode 2 + Federated Trust Model) . . . . . . . . . . . . 49
14.1. Scenario Description . . . . . . . . . . . . . . . . . . 49
14.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 50
15. Appendix G. Stand-Alone ICV Trust with idp-PoP — Temporary
Certificates for Public Device Scenarios . . . . . . . . 50
15.1. Participants and Prerequisites . . . . . . . . . . . . . 50
15.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 51
16. Appendix H. Enterprise Intranet Device Proxy Scenario
(ACME-ICV Proxy Mode) . . . . . . . . . . . . . . . . . . 52
16.1. Scenario Description . . . . . . . . . . . . . . . . . . 52
16.2. Proxy-Mode Architecture . . . . . . . . . . . . . . . . 52
16.3. Proxy Workflow . . . . . . . . . . . . . . . . . . . . . 53
16.4. Security Considerations and Limitations . . . . . . . . 54
17. Appendix I. Cross-Domain Trust — sigstore Code-Signing
Scenario (Mode 1 + OIDC-Bridged IdP) . . . . . . . . . . 54
17.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 55
17.2. Alignment with This Draft . . . . . . . . . . . . . . . 55
17.3. Simplified Workflow . . . . . . . . . . . . . . . . . . 56
17.4. Value . . . . . . . . . . . . . . . . . . . . . . . . . 57
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
19.1. Normative References . . . . . . . . . . . . . . . . . . 58
19.2. Informative References . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Introduction
Geng, et al. Expires 20 November 2026 [Page 4]
Internet-Draft ACME PK Challenge May 2026
1.1. Verification Dimensions in ACME
ACME [RFC8555] models certificate enrollment as an "Order", which
contains a set of "identifiers". Each identifier corresponds to an
"authorization" holding a set of "challenges". Existing challenges
such as "dns-01" and "http-01" address Domain Control Validation
(DCV). However, business requirements for certificate issuance also
include Proof-of-Possession (PoP) and Identity Control Validation
(ICV). These three dimensions are mutually independent and shall be
standardized as separate frameworks to allow flexible combination by
CAs.
In non-DCV scenarios such as S/MIME, code signing, device
certificates, and cross-enterprise trust-domain mutual recognition,
the core identifiers of certificates shift from domain names to email
addresses, accounts, device serial numbers, or user identity IDs.
Accordingly, the security foundation must change from "control of
communication resources" to "control of the claimed identity". The
current ACME ecosystem lacks a general-purpose identity validation
framework under autonomous CA control. The ICV framework defined in
this document aims to fill this gap.
From a PKI architectural perspective, this gap also reflects a deeper
structural issue: the lack of standardization of Registration
Authority (RA) functions. In traditional PKI deployments, the RA
verifies the identity of certificate applicants and forwards their
requests to the CA; however, RA implementations across different CAs
are not interoperable with one another. By formalizing the role of
an IdP as "an entity holding an X.509 operational certificate with a
specific EKU" (see Section 4.1 for details), this document transforms
the RA process previously relying on proprietary interfaces or manual
workflows into a standardized authorized entity that can be
automatically managed via the standard ACME protocol and validated
through standard X.509 path validation.
1.2. Review of Prior Work and Scope of This Document
The ACME Working Group has undertaken several exploratory efforts in
the area of non-DCV identity validation. This section briefly
reviews the core contributions and remaining issues of these works to
clarify the scope and positioning of this document.
*(a) [I-D.biggs-acme-sso]*：
Geng, et al. Expires 20 November 2026 [Page 5]
Internet-Draft ACME PK Challenge May 2026
This draft proposes the "sso-01" challenge and introduces the concept
of involving third-party identity providers in ACME validation. This
document inherits the "third-party IdP integration" concept from that
draft, fully returns trust-anchor control to the CA (see Section 7.6
for details), and extends it into a more general ICV framework.
*(b) [RFC8823]*：
This specification defines the "email" identifier type and the
"email-reply-00" challenge to support automated issuance of end-user
S/MIME certificates. This document does not modify the protocol
behavior of [RFC8823]; "idp-01" and "email-reply-00" may coexist and
are selected by the CA according to policy — idp-01 elevates the
security foundation to "proof of control over an identity".
*(c) [I-D.ietf-acme-client]*：
This draft pioneered the identification of automation requirements
for end-user, device, and code-signing certificates, describing
applicable use cases for ACME in these scenarios. Building upon
those scenarios, this document further provides a standardized
identity validation mechanism.
*(d) [I-D.ietf-acme-telephone]*：
This draft explored validating telephone number identifiers via
external authorities, extending ACME’s applicability to non-DNS
identifiers. This document further expands the validation scope to
more general identity control scenarios.
*(e) [I-D.ietf-acme-device-attest]*：
This draft leverages hardware trust roots such as TPM and WebAuthn to
verify device identities, targeting device trust-root and hardware
attestation scenarios. Complementary to it, this document covers two
dimensions respectively: "what the device is" and "who controls the
device".
*(f) [RFC9447] ("tkauth-01") and [I-D.ietf-acme-openid-federation]*：
The former establishes a general-purpose authoritative token
challenge framework, while the latter introduces the multi-layer
trust chain mechanism of OpenID Federation. Both provide important
references for the design of acmeIdpToken and cross-domain trust
propagation in this document. [RFC9447] does not independently
address identity validation issues; the boundary between this
document and [RFC9447] is detailed in Section 7.8.
Geng, et al. Expires 20 November 2026 [Page 6]
Internet-Draft ACME PK Challenge May 2026
In summary, existing efforts have advanced ACME adoption in non-DCV
scenarios from perspectives including identifier extension, challenge
mechanisms, and trust-chain collaboration. This document focuses on
defining a general-purpose, independently deployable identity control
validation framework with CA-led trust anchors, forming a parallel,
complementary, and extensible relationship with existing work.
1.3. Design Principles
* Separation of Concerns: ICV solely validates identity control.
DCV and PoP are handled by existing frameworks.
* Prioritize closed-loop trust within the PKI ecosystem: Reuse the
existing X.509 and ACME standards stack.
* CA Trust Anchor Supremacy over IdP: The CA proactively authorizes
IdPs and retains final decision-making authority over the
certificate lifecycle.
* Pluggable Authentication Mechanisms: Different authentication
protocols are adapted via the idp_method parameter. This document
defines a unified ACME challenge flow, while specific
authentication implementations are selected by the IdP according
to scenarios.
1.4. Solution Overview
This document defines the core components of the ICV framework: the
"idp" identifier type and the "idp-01" challenge type. ICV and DCV
are peer-level mechanisms; each can complete validation independently
and request certificates via CSR. PoP serves as an auxiliary
enhancement framework and may be used in combination with ICV.
The three deployment modes correspond to different relationships
between CAs and IdPs respectively. Mode 1 (IdP Operational
Certificate Model) applies to non-CA IdPs; Mode 2 (Intra-PKI Domain
Mutual-Recognition Model) applies to scenarios where both parties
operate private CAs; Mode 3 (CA-Integrated IdP Model) applies to
scenarios where the CA directly manages user/device identities
itself. The external protocol interactions remain consistent across
all three modes, with differences only in internal
trust-establishment paths. See Section 4 for details.
The ICV framework involves two specialized variants of ACME clients:
* ACME-ICV Client: Deployed on end-user/device side, it is
responsible for registering identity certificates for users or
devices using the "idp-01" challenge.
Geng, et al. Expires 20 November 2026 [Page 7]
Internet-Draft ACME PK Challenge May 2026
* ACME-IDP Client: Deployed on the IdP side and used only in Mode 1,
it encapsulates the logic for enrollment, renewal, and revocation
of operational certificates.
The detailed behaviors of the two types of clients are defined in
Sections 4.1 and 5.2, respectively.
This document also defines an optional X.509 certificate extension,
trust_domain_restriction (see Section 6.5). CAs *MAY* include this
extension when issuing certificates generated via the ICV path to
explicitly indicate that the trustworthiness of such certificates
relies on a specific IdP trust domain. The extension is defined as
non-critical by default to ensure deployment compatibility with the
existing TLS/S/MIME ecosystem; CAs *MAY* optionally mark it as
critical based on deployment context. Design rationale is provided
in Section 3.2, and relying-party validation logic is specified in
Section 7.10.
By default, the acmeIdpToken includes a bound_to_order claim that
cryptographically binds the token to the byte-level hash of the
current "newOrder", aligning with the order-binding semantics of the
"pk-01" challenge defined in [I-D.geng-acme-public-key]. See
Sections 6.3 and 7.9 for details.
1.5. Relationship to Existing Work
The table below summarizes the relationship between this document and
existing ACME work; detailed comparisons are provided in Sections 7.6
through 7.8.
+---------------------------------------+------------------------------------------+
| Existing Documents | Relationship |
+---------------------------------------+------------------------------------------+
| RFC 8555 | Parallel (DCV vs. ICV) |
| RFC 8823 (email-reply-00) | Enhanced security, coexistent |
| draft-ietf-acme-client | Requirements vs. Implementation |
| draft-biggs-acme-sso (Expired) | Inherited principles |
| RFC 9447 (tkauth-01) | Complementary: Identity vs. Authorization|
| draft-ietf-acme-openid-federation | Hierarchical Collaboration |
| draft-ietf-acme-device-attest | Complementary: Hardware vs. Subject |
| draft-ietf-acme-profiles | Template selection, complementary |
| draft-geng-acme-public-key (pk-01) | Auxiliary PoP Enhancement |
+---------------------------------------+------------------------------------------+
This document has no overlap or conflict with existing work in terms
of motivation, security model, or protocol behavior.
Geng, et al. Expires 20 November 2026 [Page 8]
Internet-Draft ACME PK Challenge May 2026
Note: All references to [I-D.draft-geng-acme-public-key] within this
document refer to the unsubmitted version 07.
2. Terminology and Definitions
The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*",
"*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT
RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only
when, they appear in all capitals, as shown here.
* ACME Server (AS): A CA that implements the ACME protocol and
issues certificates.
* Identity Provider (IdP): An independent service trusted by the AS
that verifies a requester’s control over a claimed identity. In
Mode 3, the IdP functionality is performed by the CA itself. In
Mode 1, the IdP acts as a formally authorized RA of the CA by
holding an operational certificate issued by the CA.
* ACME-ICV Client: A variant of the ACME client deployed on the EE
side, responsible for registering identity certificates using the
"idp-01" challenge.
* ACME-IDP Client: A variant of the ACME client deployed on the IdP
side, responsible for automated full-lifecycle management of IdP
operational certificates. Used only in Mode 1.
* IdP Identifier: An identity identifier declared in "newOrder".
Its value field is a string that identifies the claimed identity,
formatted as a URI to ensure namespace isolation across different
identity types (e.g., mailto:user@example.org
(https://mailto:user@example.org), urn:vin:1HGCM82633A123456,
urn:sn:DEV-XYZ-001).
* idp-01 Challenge: An ACME challenge type that delegates identity
control validation to the IdP.
* acmeIdpToken: A JWT [RFC7519] issued by the IdP to prove
completion of identity authentication. It is transmitted under
the field name "acmeIdpToken" in the ACME challenge response
message. It may optionally include a bound_to_order claim to
cryptographically bind the token to the current newOrder (see
Sections 6.3 and 7.9).。
* idp_method: Identifier of the authentication protocol used by the
IdP.
Geng, et al. Expires 20 November 2026 [Page 9]
Internet-Draft ACME PK Challenge May 2026
* IdP Operational Certificate: An X.509 certificate issued by the CA
to the IdP, with its EKU containing id-kp-acmeIdpTokenSigning. It
serves as the core mechanism to formally authorize the IdP as a
CA-endorsed RA. This certificate is used only in Mode 1; its
format and extension definitions are specified in Section 6.7.
The CA may require the IdP to apply for operational certificates
of different validation levels (e.g., DV or OV) per security
policies.
* Trust-Domain-Restricted Certificate: An X.509 certificate
containing the trust_domain_restriction extension defined in this
document (see Section 6.5). This extension explicitly indicates
that the trustworthiness of the certificate relies on the
specified IdP trust domain, and relying parties shall validate it
in conjunction with IdP status and policies.
* Certificate Public Key: The public key bound to the finally issued
certificate. In the ICV + PoP combined branch, this public key is
derived from the value field of the "pk" identifier in newOrder
(i.e., the base64url-encoded SubjectPublicKeyInfo [RFC5480], in
accordance with [I-D.geng-acme-public-key]); in the standalone ICV
trust-idp-PoP branch, it is taken from the confirmed_public_key
claim of acmeIdpToken; in the standalone ICV + CSR branch, it
comes from the PKCS#10 CSR provided during the finalize phase.
3. ICV Framework Architecture
3.1. Three Validation Dimensions and Three Major Protocol Frameworks
The ACME protocol suite comprises three independent validation
dimensions, each corresponding to one protocol framework.
DCV and ICV are in a parallel relationship; both can independently
complete identity validation and request certificates. PoP is an
auxiliary enhancement framework.
+-----------------------------------+-----------+---------------------------------+
| Dimension | Framework | Core Question |
+-----------------------------------+-----------+---------------------------------+
| Domain Control Validation (DCV) | RFC 8555 | Do you control this domain name?|
| Identity Control Validation (ICV) | idp-01 | Do you control this identity? |
| Proof-of-Possession (PoP) | pk-01 | Do you possess this private key?|
+-----------------------------------+-----------+---------------------------------+
Figure 1: Three Validation Dimensions and Three Major Protocol
Frameworks
Geng, et al. Expires 20 November 2026 [Page 10]
Internet-Draft ACME PK Challenge May 2026
The relationship between identifier types and frameworks is as
follows:
ACME Identifiers
|
+------------+------------+
| | |
dns pk idp
| | |
DCV PoP ICV
| (auxiliary) |
+------------+------------+
| |
| |
Domain Validation Mode Identity Validation Mode
DCV + (optional PoP) ICV + (optional PoP)
Figure 2: Relationship Between Identifier Types and Frameworks
3.2. Hierarchical Trust Model
The ICV framework introduces a hierarchical trust structure into
ACME. Unlike traditional ACME (where the CA performs end-to-end
notarization directly for domain names), this model can be summarized
with three roles:
* IdP: Performs substantive validation of an applicant’s identity
within its trust domain and outputs signed identity assertions in
the form of "acmeIdpToken".
* CA: Converts identity assertions from the IdP into final
certificates complying with the X.509 specification and manages
certificate lifecycle. The relationship between the CA and the
IdP varies by deployment mode: Mode 1 establishes authorization by
issuing IdP operational certificates; Mode 2 enables mutual trust
via pre-configured root certificates; Mode 3 has the CA act as the
IdP itself.
* Relying Party: When using a certificate, in addition to performing
standard PKI path validation, it MAY recognize the
trust_domain_restriction extension (see Section 6.5) to determine
whether to rely on the current status and policies of the IdP.
Geng, et al. Expires 20 November 2026 [Page 11]
Internet-Draft ACME PK Challenge May 2026
The core implication of this model is: when a certificate includes
the trust_domain_restriction extension, trust is jointly underpinned
by the CA and the IdP — the CA ensures compliance of the issuance
process, while the IdP guarantees the authenticity of identity
assertions. Failure of either party (e.g., revocation of the IdP’s
operational certificate, disabling of an account via IdP policy)
*SHOULD* affect a relying party’s acceptance of the certificate.
This model does not require relying parties to perform IdP status
checks for all ICV-issued certificates. Whether such checks are
conducted is determined jointly by the presence of the
trust_domain_restriction extension in the certificate and the relying
party’s local policy. Detailed relying-party validation logic is
provided in Section 7.10.
The hierarchical trust described in this section does not conflict
with the design principle of "CA trust anchor takes precedence over
IdP" in Section 1.3, as they operate at different layers:
* Framework Layer (§1.3): The CA acts as the trust anchor of the ICV
framework itself — it determines which IdPs may participate (by
issuing or refusing operational certificates), and governs final
certificate issuance and revocation. IdPs cannot obtain
authorization autonomously within the framework.
* Content Layer (this section): For identity attributes and the
assertion that "the applicant controls the claimed identity", the
IdP is the substantive source. The CA converts the IdP’s
assertions into X.509 format without re-validating the identity
content itself.
The statement in Section 7.1 that "the CA trust anchor takes
precedence over the IdP" adopts the semantics of the framework layer
and is not inconsistent with this section.
3.3. Two Standard Certificate Enrollment Modes
DCV and ICV verify the requester’s control over domain names and
identities, respectively. Since a single certificate cannot be both
a domain-validated certificate and an identity-validated certificate,
DCV and ICV are mutually exclusive in practice. Based on this
orthogonality, two standard certificate enrollment modes exist.
* *Domain Validation Mode*: DCV + optional PoP. Typical
combinations: {dns-01} or {dns-01, pk-01}.
Geng, et al. Expires 20 November 2026 [Page 12]
Internet-Draft ACME PK Challenge May 2026
* *Identity Validation Mode*: ICV + optional PoP. Typical
combinations: {idp-01}, {idp-01, pk-01}, or the standalone
ICV-trusted idp-PoP branch (not combined with pk-01, where the IdP
already provides PoP for the certificate public key during
authentication).
The identity validation mode is subdivided into three branches, whose
differences are summarized collectively in the synergy matrix in
Section 3.5.
3.4. Identity Identifier Types and Coverage Scope
This document defines the "idp" identifier type, whose value field
identifies the claimed identity. The ICV framework covers two broad
categories of identities:
* Physical Device Identity: Device serial numbers, vehicle VINs,
etc. Attestation protocols are typically provided by chip vendors
or device manufacturers. Such identity identifiers do not
inherently imply a public key. When the IdP establishes PoP of
the device private key during identity validation (e.g., TPM
endorsement signatures, WebAuthn assertions), the standalone
ICV-trusted idp-PoP branch applies (see Appendix H); otherwise,
the standalone ICV + CSR branch applies.
* Subject (Human or AI) Account Identity: User email addresses,
employee IDs, AI agent identifiers, and asserted identities
indirectly held by other subjects upon human authorization.
Attestation protocols are provided by the IdP, and any branch may
be used.
3.5. Synergy Matrix of ICV and PoP
The identity validation mode is subdivided into three branches, whose
differences are summarized below in a consolidated manner.
Geng, et al. Expires 20 November 2026 [Page 13]
Internet-Draft ACME PK Challenge May 2026
+----------------+--------------+----------------------------------+--------------+
| Branch | newOrder | Certificate Public Key Source | finalize |
| | identifiers | | body |
+----------------+--------------+----------------------------------+--------------+
| Standalone ICV | [{idp}] | SPKI from the CSR submitted | {"csr":...} |
| + CSR| | during the finalize phase | |
+----------------+--------------+----------------------------------+--------------+
| Standalone ICV | [{idp}] | acmeIdpToken.confirmed_public_key| {} empty |
|(IdP-PoP Trusted)| | | object |
+----------------+--------------+----------------------------------+--------------+
| ICV + PoP | [{idp}, {pk}]| SPKI decoded from the value of | {} empty |
| | | the "pk" identifier | object |
+----------------+--------------+----------------------------------+--------------+
Figure 3: Synergy Matrix of the Three Branches of Identity
Validation Mode
Applicability Notes:
* Standalone ICV + CSR applies to scenarios where identity
authentication and certificate keys are decoupled, e.g.,
multiple-purpose certificates associated with the same IdP
identity (see Appendix A).
* Standalone ICV with IdP-PoP trust applies to scenarios where the
identity key and certificate key are consolidated, or deployments
such as shared public devices where an additional pk-01 challenge
is impractical (see Appendices G and H).
* ICV + PoP applies to high-security scenarios requiring direct CA
validation of certificate private-key ownership (acme-PoP), or
post-quantum KEM algorithms for which CSRs are not feasible.
4. Deployment Modes
The external protocol interactions remain consistent across the three
deployment modes; they differ only in how the CA establishes trust in
IdPs and how trust anchors are configured. This section describes
each mode individually, followed by selection guidance provided in
Section 4.4.
4.1. Mode 1: IdP-Operated Certificate Model
This mode applies to non-CA IdPs, including enterprise internal LDAP/
OAuth services, content platform user systems, social media identity
systems, and others. The CA establishes trust by issuing dedicated
operational certificates to the IdP, enabling the IdP to participate
in the ICV framework without operating its own CA.
Geng, et al. Expires 20 November 2026 [Page 14]
Internet-Draft ACME PK Challenge May 2026
An IdP-operated certificate is a standardized RA credential for an
IdP to join the ICV framework; its EKU includes
id-kp-acmeIdpTokenSigning (see Section 6.7 for details). This
mechanism replaces vendor-specific RA-CA integration interfaces and
manual authorization processes used in traditional PKI with a single
ACME certificate enrollment. Any ACME-capable IdP only needs to
apply for one operational certificate to obtain RA qualification.
4.1.1. Trust Establishment
The IdP applies to the CA for a dedicated operational certificate
(EKU id-kp-acmeIdpTokenSigning). The CA verifies the IdP’s
eligibility per policy. Depending on the risk level, verification
may be categorized as follows:
* DV Level: Verifies the IdP’s control over its domain via the
"dns-01" or "http-01" challenge. Applicable to low-risk
scenarios.
* OV/EV Level: Requires the IdP to complete Organization Validation
(OV) or even Extended Validation (EV). OV-level validation can be
automated via the following approaches:
(1) Pre-validation plus EAB mechanism: The IdP first submits
organizational identity materials to the CA via out-of-band means
(or initial manual review). After the CA completes verification,
it issues an External Account Binding (EAB) credential for the
IdP. Subsequent ACME-IDP clients present the EAB when registering
accounts or requesting operational certificates, allowing the CA
to automatically associate the account with the pre-validated
organization.
(2) Manual administrator approval: For on-premises deployments, CA
administrators may confirm the IdP’s organizational identity
through a manual approval workflow.
Upon successful validation, the CA issues the operational
certificate. It is RECOMMENDED that the operational certificate have
a validity period of no more than one year and support ACME renewal.
The CA *SHOULD* explicitly state the validation-level requirements
for such operational certificates in its Certificate Practice
Statement (CPS).
Geng, et al. Expires 20 November 2026 [Page 15]
Internet-Draft ACME PK Challenge May 2026
4.1.2. ACME-IDP Client
The ACME-IDP client is a specialized variant of the ACME client
deployed on the IdP side. It encapsulates logic for requesting,
renewing, and revoking operational certificates on top of standard
ACME client behavior (per [RFC8555]).
The ACME-IDP client SHOULD support the following functions:
* Initial Enrollment: Upon initial IdP deployment, automatically
create an ACME account (or use a pre-provisioned account key),
submit a "newOrder" (declaring the IdP identity identifier with
profile [I-D.ietf-acme-profiles]: "idp-op-cert"), complete
CA-required validation challenges, submit a CSR, and obtain the
operational certificate. The client *SHOULD* support the EAB
mechanism to enable automated issuance of OV certificates.
* Automated Renewal: Automatically renew the operational certificate
prior to its expiration. Renewal is *RECOMMENDED* to be triggered
when 30% of the certificate validity period remains.
* Automated Revocation: Automatically submit a revocation request to
the CA when the IdP no longer acts as an IdP.
* Challenge Handling: *SHOULD* support automated processing of the
"dns-01" or "http-01" challenges.
The private key of the operational certificate for the ACME-IDP
client *MUST NOT* be persistently stored in plaintext. Use of an
HSM, TEE, or OS-level secure key storage mechanism is RECOMMENDED.
In case of private-key compromise or suspected compromise, the
current operational certificate *MUST* be revoked immediately and a
new one re-enrolled.
The ACME-IDP client does not participate in online interactions for
end-user identity authentication; it only manages operational
certificates on the IdP side.
Geng, et al. Expires 20 November 2026 [Page 16]
Internet-Draft ACME PK Challenge May 2026
+--------------------+---------------------+------------------+-----------------------+
| Client Type | Deployment Location | Certificate Type | Core Functionality |
+--------------------+---------------------+------------------+-----------------------+
|Standard ACME Client| EE-side |Domain Certificate| DCV + Certificate |
| | (Domain Scenarios) |Certificate Type | Enrollment |
| | | | |
| ACME-IDP Client | IdP-side | IdP Operational |Operational Certificate|
| | | Certificate |Lifecycle Management |
| | | | |
| ACME-ICV Client | EE-side |Identity |ICV + Identity |
| |(Identity Scenarios) | Certificate |Certificate Enrollment |
+--------------------+---------------------+------------------+-----------------------+
Figure 4: Client Roles in the ICV Framework
4.1.3. Subsequent Identity Validation
After the IdP obtains an operational certificate, it uses the
corresponding certificate private key to sign the acmeIdpToken in
subsequent "idp-01" challenges. When validating the token, the CA
verifies the operational certificate via standard X.509 certificate
path validation. The validation level (DV / OV / EV) of the
operational certificate determines the CA’s trust in the IdP, which
further constrains the permitted types of end-entity certificates
issued.
4.2. Mode 2: PKI Intra-Domain Mutual-Trust Model
This mode is used when both the CA and the IdP operate private CAs.
Deploying private CAs is standard practice in enterprise IT
environments (e.g., Windows Server AD CS, EJBCA). When end-to-end
secure communication is required between two organizations, each
party most likely runs its own private CA.
In this mode, participants exchange root certificates based on a
bilateral mutual-trust agreement, and the ACME server directly
configures the peer CA’s root or subordinate CA certificate as a
trust anchor. The peer CA directly signs the acmeIdpToken using its
existing CA certificate. The issuing CA retains final authority over
the lifecycle of end-entity certificates. This mode can be
cross-domain (where both parties belong to separate organizations) or
intra-domain (between CAs of different departments or tiers within a
single organization).
Geng, et al. Expires 20 November 2026 [Page 17]
Internet-Draft ACME PK Challenge May 2026
In cross-domain deployments, the CA *SHOULD* include the
trust_domain_restriction extension in issued certificates, where the
idpIdentifier points to the peer-organization IdP participating in
mutual trust, enabling relying parties to correctly interpret the
certificate’s trust scope.
4.3. Mode 3: CA-Integrated IdP Model
This mode applies when the CA itself directly manages identity
enrollment and authentication for users or devices. The CA
concurrently acts as the IdP—performing identity registration and
control validation, and issuing certificates accordingly. The
idp_url in the "idp-01" challenge points to the CA’s own
authentication endpoint, or the CA may directly complete challenge
validation based on internal authentication results.
This mode has seen extensive product-grade industry adoption,
including integrations such as Windows Server AD CS with Active
Directory, HashiCorp Vault PKI (ACME-enabled since version 1.14),
Foxpass Cloud PKI with Microsoft Entra ID / Google Workspace, and
GlobalSign Auto Enrollment Gateway with AD.
In this mode, the CA functions as a unified identity and certificate
management platform with no need for an external IdP. External
protocol interactions for "idp-01" remain unchanged to ensure
interoperability across all three modes. Since the trust domains of
the CA and IdP overlap, the CA generally does not need to include the
trust_domain_restriction extension in issued certificates, unless it
explicitly intends to mark the authentication source for consistency
with certificates issued under Mode 1 and Mode 2.
4.4. Mode Selection Guidance
The following decision criteria help deployers select the appropriate
mode:
Question 1: Does the CA itself manage enrollment and authentication for target identities?
├─ Yes --> Mode 3 (CA-Integrated IdP)
└─ No ──↓
Question 2: Does the organization to which the identity belongs operate a private CA trusted by the CA (or one for which trust can be established via root-certificate cross-recognition)?
├─ Yes --> Mode 2 (PKI Intra-Domain Mutual-Trust)
└─ No ──↓
Question 3: Does the organization to which the identity belongs operate a non-CA IdP (e.g., enterprise SSO, content-platform account systems)?
└─ Yes --> Mode 1 (IdP Operational Certificate)
In practice, all three modes may coexist within a single CA: the CA
may use Mode 3 for its own organization, Mode 2 for federation
partners, and Mode 1 for external IdPs.
Geng, et al. Expires 20 November 2026 [Page 18]
Internet-Draft ACME PK Challenge May 2026
+---------------+-------------------------+---------------------------+-------------------------+
| Dimension | Mode 1 | Mode 2 | Mode 3 |
+---------------+-------------------------+---------------------------+-------------------------+
| CA-IdP | Separated (Non-CA IdP) | Separated (Both are CAs) | Integrated (CA = IdP) |
| Relationship | | | |
| | | | |
| Trust Anchor | Operational certificate | Mutual root certificates | CA itself |
| | issued by the CA | | |
| | | | |
| Trust Domain | Intra-domain | Cross-domain/intra-domain | Intra-domain |
| | | | |
| IdP Client | ACME-IDP Client | Not required | Not required |
| | | | |
| Typical Use | Enterprise IdP | Inter-enterprise | AD CS + AD, Vault PKI, |
| | + External CA | PKI mutual-trust | Foxpass |
| | | | |
| Privacy | Low to Medium | Medium to High | Low to Medium |
+---------------+-------------------------+---------------------------+-------------------------+
Figure 5: Comparison of the Three Deployment Modes
5. ICV Framework Protocol Flow
This section describes the overall behavior of the ICV framework from
client- and process-oriented perspectives. Section 5.1 presents the
conceptual timeline of three-party interactions, while Section 5.2
enumerates the specific responsibilities of the ACME-ICV client.
Field formats, triggering conditions, validation rules, and extension
definitions on the server/IdP side are specified in Section 6.
5.1. Overall Interaction Model
The ICV framework follows the identifier-authorization-challenge
architecture of the ACME protocol. External interactions for the
"idp-01" challenge remain consistent regardless of the deployment
mode.
Geng, et al. Expires 20 November 2026 [Page 19]
Internet-Draft ACME PK Challenge May 2026
EE (ACME-ICV Client) IdP ACME Server (CA)
| | |
|== (1) newOrder ==============================================>|
| identifiers: [{idp, "<identity>"}] |
| | |
|<= (2) order ==================================================|
| authz: [.../authz/idpXXX] |
| | |
|== (3) GET authz =============================================>|
|<= (4) challenge ==============================================|
| [{type:"idp-01", idp_url, idp_method}] |
| | |
|== (5) authn (by idp_method) ====>| |
|<= (6) acmeIdpToken ==============| |
| | |
|== (7) POST challenge ========================================>|
| {acmeIdpToken: "<jwt>"} |
| | |
|<= (8) challenge: valid =======================================|
|<= (9) order: ready ===========================================|
| | |
|== (10) POST finalize (Branch per Section 3.5) ===============>|
|<= (11) certificate ===========================================|
Figure 6: Overall Interaction Model of the ICV Framework
(Conceptual View)
Notes:
1. In Mode 3, the IdP and CA are operated by the same entity. Steps
(5)–(6) are performed internally. The CA may still optionally
issue an acmeIdpToken externally to maintain interoperability.
Regardless of the deployment mode, acmeIdpToken by default
includes the bound_to_order claim to bind the token to the
current "newOrder" (see Section 6.3).
2. The difference between the standalone ICV + CSR branch and the
standalone ICV trusting idp-PoP branch occurs only at Step (10).
The combined ICV + PoP branch additionally declares the "pk"
identifier in the "newOrder" and independently completes the
"pk-01" challenge (see [I-D.geng-acme-public-key]).
Geng, et al. Expires 20 November 2026 [Page 20]
Internet-Draft ACME PK Challenge May 2026
5.2. ACME-ICV Client Behavior
The ACME-ICV client is a variant of the ACME client deployed on the
EE side, used to request identity-bound certificates via the "idp-01"
challenge. Building on standard ACME client behavior (per
[RFC8555]), it encapsulates interactions with the IdP as well as
logic for obtaining and submitting the acmeIdpToken. Regardless of
the deployment mode adopted, the core behavior of the ACME-ICV client
remains consistent: the client only needs to know the idp_url and
idp_method, and does not need to perceive whether the IdP is an
external standalone entity or integrated within the CA itself.
The ACME-ICV client *SHOULD* support the following behaviors:
* Identifier Declaration: Declare the "idp" identifier in the
"newOrder" request to trigger the "idp-01" challenge (trigger
conditions specified in Section 6.1.1), where its value represents
the identity of the user or device.
* raw_newOrder Caching: The client *MUST* retain the exact byte
sequence of the JWS protected payload of the "newOrder" request
locally, and compute SHA-256(raw_newOrder) using the identical
byte sequence during the "idp-01" challenge phase. The client
*MUST NOT* re-serialize parsed JSON for use as raw_newOrder (see
Section 6.3).。
* "idp-01" Challenge Handling: Identify the "idp-01" challenge
within the authorization object, parse the idp_url and idp_method
fields, interact with the IdP via the specified authentication
protocol to complete identity authentication. When requesting the
IdP to issue an acmeIdpToken, the client shall pass
base64url(SHA-256(raw_newOrder)) to the IdP as the bound_to_order
hint (the specific delivery mechanism is defined per individual
idp_method), and finally obtain the acmeIdpToken and submit it to
the challenge URL.
* Finalization-phase Processing: Submit the CSR, an empty request,
or coordinate with the validation result of the "pk-01" challenge
according to the selected branch defined in the coordination
matrix in Section 3.5.
6. Protocol Details
6.1. The "idp-01" Challenge Object
Geng, et al. Expires 20 November 2026 [Page 21]
Internet-Draft ACME PK Challenge May 2026
6.1.1. Trigger Conditions
When the identifiers array in a "newOrder" request contains an
identifier of type "idp", the ACME server *MUST* create an
authorization object for this identifier, and the challenges array of
this authorization object *MUST* contain exactly one challenge of
type "idp-01".
The server *SHOULD NOT* return an "idp-01" challenge for identifiers
of non-"idp" types.
The server *MAY* offer other future-defined compatible challenge
types side-by-side within the same authorization object; the client
*MAY* select any one of them to complete validation per local policy
(per [RFC8555] §7.1.4).
6.1.2. Challenge Object Fields
The challenge object extends the standard fields defined in [RFC8555]
§7.1.5 and §8 (such as type, url, status, validated, and error) with
the following additional fields:
+----------------------+--------+----------------------------------+
| Field | Req. | Description |
+----------------------+--------+----------------------------------+
| idpIdentifier | Yes | Unique identifier generated by |
| | | the server for this challenge |
| | | |
| idp_url | Yes | IdP validation endpoint URL |
| | | |
| idp_method | Yes | Authentication protocol |
| | | (see Section 6.2) |
| | | |
| idp_cert_fingerprint | No | Fingerprint of the IdP-operated |
| | | certificate (Mode 1) |
| | | |
| deployment_mode | No | "idp-op-cert", "pki-intra", or |
| | | "ca-idp" |
+----------------------+--------+----------------------------------+
Figure 7: Fields of the "idp-01
The idpIdentifier is independently generated by the server for each
challenge with no less than 128 bits of entropy. It serves as a
unique challenge identifier and anti-replay mechanism, ensuring that
an acmeIdpToken issued for one "idp-01" challenge cannot be
re-consumed by the server. Byte-level order binding is enforced by
the bound_to_order claim within the acmeIdpToken (see Section 6.3).
Geng, et al. Expires 20 November 2026 [Page 22]
Internet-Draft ACME PK Challenge May 2026
The two mechanisms are complementary: idpIdentifier prevents replay
at the challenge level, while bound_to_order prevents cross-order
replay of tokens.
6.2. IdP Authentication Methods
The CA selects the authentication protocol adopted by the IdP via the
idp_method field. Values of idp_method are managed jointly by the
initial set defined in Sections 6.2.1 and 6.2.2 of this document and
the IANA registry (Section 8), covering both account identities and
device identities.
6.2.1. Account Identity Authentication Methods
* pkic: The IdP holds a certificate trusted by the AS. If the
identity exists in the form of a public key, the IdP verifies that
the applicant possesses the private key bound to the identity via
idp-PoP (e.g., requiring the applicant to sign the idpIdentifier,
with the IdP verifying the signature using the public key from its
trusted certificate).
* opaque [RFC9807]: Password-Authenticated Key Exchange, verifying
possession of the private key bound to the identity during the AKE
phase.
* webauthn [WebAuthn]: Hardware-bound two-factor authentication.
* internal: Used for Mode 3 (CA-integrated IdP). This method
indicates that IdP functionality is performed by the CA itself,
which directly authenticates the applicant’s identity using its
internal identity store. No external JWT token is required for
identity verification; for protocol interoperability, the CA may
optionally issue an acmeIdpToken.
6.2.2. Device Identity Authentication Methods
Device Identity Authentication Methods are used to verify a device’s
control over its claimed physical identity identifier. Trust anchors
are typically third-party entities independent of the CA (e.g., chip
vendors, device manufacturers).
* device-puf: Based on Physical Unclonable Functions.
* device-tpm: Based on TPM Endorsement Keys.
* device-vin: Based on Vehicle Identification Numbers.
* device-sn: Based on device serial numbers.
Geng, et al. Expires 20 November 2026 [Page 23]
Internet-Draft ACME PK Challenge May 2026
+-------------+-------------+---------------------------------+---------------+
| Identifier | Type | Description | Reference |
+-------------+-------------+---------------------------------+---------------+
| pkic | Account | PKI certificate chain validation| This document |
| opaque | Account | OPAQUE protocol | [RFC9807] |
| webauthn | Account | WebAuthn Level 2 | [WebAuthn] |
| internal | Account | Internal CA authentication | This document |
| device-puf | Device |PUF challenge-response validation| This document |
| device-tpm | Device | TPM EK validation | This document |
| device-vin | Device | Vehicle VIN validation | This document |
| device-sn | Device | Device serial number validation | This document |
+-------------+-------------+---------------------------------+---------------+
Figure 8: Initial Set of IdP Authentication Methods (Extensible
for Future Use)
6.3. Format of the "acmeIdpToken"
The JWT [RFC7519] issued by the IdP (encoded as JWS [RFC7515])
contains the following claims:
Geng, et al. Expires 20 November 2026 [Page 24]
Internet-Draft ACME PK Challenge May 2026
+-----------------------+--------+--------------------------------+
| Claim | Req. | Description |
+-----------------------+--------+--------------------------------+
| iss | Yes | IdP identifier |
| sub | Yes | Applicant identity identifier |
| | | (may be pairwise pseudonym) |
| aud | Yes | AS identifier |
| iat | Yes | Issued-at time |
| exp | Yes | Expiration time (recommended |
| | | ≤ 5 minutes) |
| jti | Yes | Unique token identifier |
| | | (one-time use) |
| idpIdentifier | Yes | Matches the value in the |
| | | challenge object |
| idp_method | Yes | Authentication method used |
| bound_to_order | Yes* | base64url(SHA-256( |
| | | raw_newOrder)). The client |
| | | informs the IdP of the byte- |
| | | level hash of the current |
| | | newOrder during IdP |
| | | authentication; the IdP echoes |
| | | this value in this claim to |
| | | cryptographically bind the |
| | | token to the current order |
| | | (see Section 7.9). |
| nbf | No | Standard JWT [RFC7519] claim; |
| | | if present, the CA MUST |
| | | validate per RFC 7519 §4.1.5. |
| confirmed_public_key | No | Present only when the IdP uses |
| | | a public-key authentication |
| | | protocol; carries the |
| | | base64url-encoded SPKI of the |
| | | certificate public key |
+-----------------------+--------+--------------------------------+
Figure 9: `acmeIdpToken` JWT Claims
*Note** bound_to_order: Required by default (*SHOULD*). The CA
SHOULD require this claim to be present and match during validation.
For specific backward-compatibility scenarios, the CA policy MAY
allow its absence; however, the CA *MUST* explicitly document the
security consequences of accepting weak binding in its CPS (see
Section 7.9).
Geng, et al. Expires 20 November 2026 [Page 25]
Internet-Draft ACME PK Challenge May 2026
The exact byte definition of raw_newOrder is consistent with §10.1.1
in [I-D.geng-acme-public-key]: the raw byte sequence of the JWS
protected payload after BASE64URL-DECODE and before JSON parsing.
The client *MUST NOT* re-serialize the parsed JSON for use as
raw_newOrder.
6.4. Challenge Response and Server Validation
ACME-ICV clients submit to the challenge URL via a standard
authenticated ACME POST request:
{"acmeIdpToken": "<jwt>"}
Upon receiving the response, the server performs validation following
these steps:
1. Determine the trust anchor according to the deployment mode
(operational certificate path / cross-recognized root certificate
/ internal identity system).
2. For Mode 1 / Mode 2, verify the JWS signature of the acmeIdpToken
and validate the IdP certificate path per [RFC5280]. For Mode 3,
the CA’s internal identity system directly provides the
validation result.
3. Validate token claims according to the following rules:
a. iss and aud *MUST* match the expected values from the
challenge object;
b. exp *MUST* be later than the current time. If the token
includes nbf, it *MUST* be earlier than or equal to the current
time (per [RFC7519] §4.1.5);
c. jti *MUST NOT* have been consumed within the jti replay window
(see Section 7.4);
d. idpIdentifier and idp_method *MUST* match those in the
challenge object.
4. If the token contains the bound_to_order claim, the server *MUST*
perform a byte-level comparison against the SHA-256 value
computed server-side from the persisted raw_newOrder (or
equivalent storage). Return
urn:ietf:params:acme:error:badIdpToken on mismatch. If CA policy
requires this claim to be present but it is missing from the
token, the server *SHOULD* reject the request likewise.
Geng, et al. Expires 20 November 2026 [Page 26]
Internet-Draft ACME PK Challenge May 2026
5. Establish the source of the certificate public key per the
selected branch (see Section 3.5).
6.5. Trust-Domain-Restricted Certificate Extension
This section defines a new X.509 certificate extension
trust_domain_restriction, which a CA *MAY* include when issuing an
ICV certificate to explicitly indicate that the certificate’s
trustworthiness depends on the specified IdP trust domain.
6.5.1. Extension Definition
Proposed OID: id-pe-acme-idp-trust-domain, assigned under the PKIX
private extension arc (final value to be allocated by IANA, see
Section 8). A certificate *SHALL* contain at most one
trust_domain_restriction extension.
ASN.1 Syntax:
id-pe-acme-idp-trust-domain OBJECT IDENTIFIER ::= { TBD }
TrustDomainRestriction ::= SEQUENCE {
idpIdentifier UTF8String,
idpPolicyURI IA5String OPTIONAL,
idpAssertedAttributes SEQUENCE OF AssertedAttribute
OPTIONAL
}
AssertedAttribute ::= SEQUENCE {
type OBJECT IDENTIFIER,
value UTF8String -- Length MUST be ≤ 256 octets
}
Field Description:
* idpIdentifier: The URI of the IdP (matching idp_url in the
challenge object), or the Subject DN of the IdP’s operational
certificate.
* idpPolicyURI: Optional. A URI pointing to the IdP’s current
certificate policy statement, enabling relying parties to retrieve
the latest policy on demand.
* idpAssertedAttributes: Optional. A subset of attributes asserted
by the IdP in the acmeIdpToken. Attribute types *MUST* be
selected from the IANA-registered allowed set (see Section 8); the
CA *MUST NOT* pass unregistered-type attributes into this field.
Geng, et al. Expires 20 November 2026 [Page 27]
Internet-Draft ACME PK Challenge May 2026
6.5.2. Critical Marking Policy
This extension *SHOULD* be issued as non-critical by default,
ensuring that existing relying parties such as TLS libraries and S/
MIME clients that do not recognize this extension can still read
standard certificate fields. This is a deployment-compatibility
choice for this version.
A CA *MAY* mark this extension as critical under the following
conditions:
* The CA knows that all target relying-party implementations support
this extension; or
* Deployment within a closed ecosystem (e.g., enterprise intranets,
industry-specific PKI), where progress of relying-party upgrades
can be guaranteed.
Marking this extension as critical forces relying parties that do not
recognize the extension to reject the certificate, providing
fail-closed security guarantees; however, this comes at the cost of
blocking unupgraded relying parties. A CA *SHOULD* clearly document
the timeline for critical-flag upgrades and the affected deployment
contexts in its Certificate Practice Statement (CPS).
6.5.3. Boundary with the RFC 5280 certificatePolicies Extension
[RFC5280] §4.2.1.4 defines the certificatePolicies extension for
declaring policy OIDs that a certificate adheres to. The
trust_domain_restriction extension differs in the following aspects:
* certificatePolicies defaults to non-critical and carries semantics
oriented toward a "policy compliance statement";
trust_domain_restriction carries runtime-resolvable idpIdentifier
and an optional idpPolicyURI, enabling relying parties to actively
verify the current state of the IdP.
* certificatePolicies cannot convey the set of attributes asserted
by the IdP at issuance time (idpAssertedAttributes), which serve
as part of audit and policy inputs within the ICV framework.
* certificatePolicies is typically used by relying parties to
“identify whether a certificate conforms to an expected policy
category” and is not employed for real-time validation logic.
Geng, et al. Expires 20 November 2026 [Page 28]
Internet-Draft ACME PK Challenge May 2026
A CA *MAY* use both extensions concurrently: certificatePolicies to
mark the policy OID associated with an ICV certificate, and
trust_domain_restriction to carry information required for real-time
IdP validation. The two extensions do not conflict with each other.
6.5.4. CA Writing Requirements
When a CA decides to issue a certificate containing the
trust_domain_restriction extension:
* idpIdentifier *MUST* match the iss claim within the acmeIdpToken
and the idp_url in the idp-01 challenge object;
* The content of idpAssertedAttributes shall be taken directly from
the corresponding field in the acmeIdpToken, and attribute types
*MUST* be IANA-registered (see §8);
* A CA *SHOULD NOT* map attributes asserted by the IdP into Subject
Directory Attributes or non-standard extensions, to prevent
semantic proliferation.
6.6. Error Types
This section lists the error types defined by this extension. All
errors use the ACME error URN namespace prefix
"urn:ietf:params:acme:error:" (per [RFC8555] §6.7):
+-----------------------------------------+----------------------------------------------------+
| Error URN | Trigger Condition |
+-----------------------------------------+----------------------------------------------------+
| urn:ietf:params:acme:error:badIdpToken | Invalid token signature, reused jti |
| | or mismatched bound_to_order |
| urn:ietf:params:acme:error:rejectedIdpId| Mismatched identifier |
| | or iss/aud claims |
| urn:ietf:params:acme:error:idpTimeout | Expired token |
| urn:ietf:params:acme:error: | CA policy requires issuance of a certificate |
| trustDomainRestrictionViolation | with the trust_domain_restriction extension, |
| | but the acmeIdpToken content fails to |
| | satisfy population requirements for this extension|
+-----------------------------------------+----------------------------------------------------+
Figure 10: Error Types
6.7. IdP Operational Certificate Format and Interoperability
The IdP operational certificate is the core mechanism for formalizing
an IdP as a CA-authorized Registration Authority (RA).
Geng, et al. Expires 20 November 2026 [Page 29]
Internet-Draft ACME PK Challenge May 2026
6.7.1. Certificate Format Requirements
An IdP operational certificate *SHOULD* follow the X.509 v3
certificate format specification ([RFC5280]) and shall meet the
following specific requirements:
* Certificate type: X.509 v3 end-entity certificate.
* Extended Key Usage (EKU): *MUST* include id-kp-acmeIdpTokenSigning
(see IANA registration in Section 8).
* Key Usage: *MUST* include digitalSignature.
* Basic Constraints: The CA flag *MUST* be FALSE.
* Subject DN: *SHOULD* at least contain CN = IdP domain name or
organization identifier; OV-level certificates *SHOULD*
additionally include the O and C fields.
* Subject Alternative Name (SAN): *SHOULD* contain the dNSName of
the IdP validation endpoint, matching the domain in the idp_url
field.
* CRL Distribution Points: *MAY* be included.
* Validity period: Controlled by CA policy; recommended not to
exceed one year, with support for ACME renewal.
6.7.2. Interoperability with Existing IdPs
For existing deployed IdP systems, integration can be achieved via
the following approaches:
* LDAP/AD-based IdPs: Deploy an ACME-IDP client alongside existing
AD domain controllers or LDAP servers. Use enterprise-native
LDAP/AD connectors for user authentication, while the ACME-IDP
client solely handles operational certificate management and
acmeIdpToken issuance.
* SAML/OIDC-based IdPs (e.g., Shibboleth, Keycloak): The ACME-IDP
client provides protocol translation from SAML/OIDC to
acmeIdpToken (JWT), enabling existing IdPs to participate in the
ICV framework without modifying their core authentication logic.
7. Security Considerations
Geng, et al. Expires 20 November 2026 [Page 30]
Internet-Draft ACME PK Challenge May 2026
7.1. Trust Anchor Levels and Threat Model
The CA is the issuer of the final certificate and holds a higher
trust-anchor level than the IdP. The IdP assists the CA in proving
the binding between an identity and a public key. When a CA adopts
the standalone ICV (trust-idp-PoP) branch, the CA fully relies on the
IdP’s validation results for identity-public-key PoP — the security
boundary of this mode is tied to the security strength of the IdP’s
authentication protocol.
Major threats and mitigations are as follows:
* Compromise of the operational certificate private key (Mode 1): If
the IdP operational certificate private key is compromised, an
attacker may forge tokens. The CA mitigates this risk via
certificate validity periods, revocation mechanisms, and
key-strength requirements. Compromise of OV-level operational
certificates has more severe consequences; IdPs are recommended to
use HSMs and shorten certificate validity periods.
* CA issuance review: The CA *MUST* verify the IdP identity, with
policies defined in the CPS.
* Root certificate management (Mode 2): Root certificate exchange
*MUST* occur over secure channels. Compromise or mis-issuance of
either party’s root certificate impacts the entire cross-trust
system.
* Forged identity control verification following IdP compromise:
Defense-in-depth can be provided via "pk-01".
* Auditing of internal identity authentication (Mode 3): When the CA
itself acts as the IdP, the CA’s identity authentication logs and
certificate issuance decisions *SHOULD* be covered by audits
defined in the CPS.
7.2. Layered PoP Verification
Within the ICV framework, PoP verification can occur at two layers:
* idp-PoP: When an IdP’s authentication method uses public-key
authentication, the IdP verifies during authentication that the
applicant holds the private key bound to the identity.
* acme-PoP: The CA directly verifies via the "pk-01" challenge that
the applicant holds the private key corresponding to the
certificate public key, entirely independent of the IdP.
Geng, et al. Expires 20 November 2026 [Page 31]
Internet-Draft ACME PK Challenge May 2026
Based on the type of the IdP’s authentication method and its own
policies, the CA decides whether to trust idp-PoP and whether to
additionally require acme-PoP.
7.3. Certificate Lifecycle and Authentication Strength
The certificate lifecycle *SHOULD* match the PoP security strength of
the IdP authentication method:
* Low-entropy credentials (e.g., OPAQUE passphrases): Issue only
short-lived certificates (hours to days), and *SHOULD* require
additional acme-PoP.
* Hardware-bound two-factor authentication (e.g., WebAuthn):
Longer-lived certificates (months to one year) may be issued, with
acme-PoP optional.
* Existing PKI certificate chains: PoP security strength matches
that of the source CA; long-lived certificates are recommended.
* Internal identity authentication (e.g., LDAP, AD integration):
Security strength depends on the internal authentication protocol
strength of the CA.
Specific policies are defined in the CA’s CP/CPS.
7.4. Timeliness
The token validity period *MUST NOT* exceed 5 minutes, and the jti
shall be single-use only. The exact duration of the jti replay
window is chosen by the CA implementation, but it *MUST* cover the
maximum possible token validity period.
Even in the extreme scenario where an attacker bypasses the jti
replay window, the bound_to_order claim (see Sections 6.3 and 7.9)
restricts the token to the "newOrder" for which it was generated,
preventing attackers from redirecting it to other orders. This
provides defense-in-depth for timeliness protection.
7.5. Privacy
The IdP learns the user identity during authentication. The sub
claim *SHOULD* use pairwise pseudonyms (distinct values per aud), and
the AS shall use sub only for the minimum scope required for
certificate issuance. In cross-domain deployments where the CA and
IdP belong to different trust domains, cross-domain transmission of
identity information introduces additional privacy risks. Under
Mode 3 where the CA acts as the IdP itself, identity information is
Geng, et al. Expires 20 November 2026 [Page 32]
Internet-Draft ACME PK Challenge May 2026
transmitted within a single trust domain, substantially reducing
privacy risks compared with cross-domain deployments.
Using distinct pairwise pseudonyms for different aud values mitigates
correlation attacks (linking the same user across multiple IdPs via a
shared sub): a sub value for one aud *SHOULD NOT* be reused across
other aud values, so as to preserve unlinkability among relying
parties.
The idpAssertedAttributes field within the trust_domain_restriction
extension persists IdP-asserted attributes into the X.509
certificate, exposing them to all relying-party processing paths
(including CT logs). The CA *SHOULD* assess privacy consequences
when selecting which attributes to embed:
* Embed only attributes that are operationally necessary and
consented to by the applicant;
* Attributes involving sensitive categories (e.g., health, religion,
internal organizational roles) *SHOULD* be excluded by default
unless explicitly required by the relying-party context;
* Prefer the “pairwise pseudonym + role” pattern for expressing
access rights over “real-name + detailed attributes” when
feasible.
Before making authorization decisions using idpAssertedAttributes,
relying parties *SHOULD* constrain the set of acceptable attribute
types in local policy (see Step 4 in Section 7.10) to prevent
privilege escalation triggered by unexpected attributes.
7.6. Comparison with the SSO/OAuth Security Model
The three-party interaction model of "idp-01" is structurally similar
to SSO/OAuth, yet fundamentally different in trust-anchor
architecture: SSO/OAuth adopts a single-trust-anchor structure (the
IdP is the sole trust anchor), whereas "idp-01" features a
dual-trust-anchor structure (the CA ranks higher than the IdP, with
the CA granting active trust via operational certificates or
pre-provisioned root certificates).
Geng, et al. Expires 20 November 2026 [Page 33]
Internet-Draft ACME PK Challenge May 2026
+-------------------+------------------+----------------------------+
| Dimension | SSO/OAuth | idp-01 |
+-------------------+------------------+----------------------------+
| Trust Anchor | Single trust | Dual trust anchor |
| Structure | anchor (IdP only)| (CA superior to IdP) |
| | | |
| Token Semantics | Authorizes access| One-time credential |
| | to online | triggering long-term |
| | resources | certificate issuance |
| | | |
| Security Impact | Authorization | Certificate persists, |
| of Output | ends on token | impact lasts months/years |
| | invalidation | |
| | | |
| PoP Verification | Single-layer | Layered verification: |
| | performed by IdP | idp-PoP + optional acme-PoP|
| | | |
| Certificate | N/A | Governed by |
| Lifecycle Control | | authentication strength |
| | | |
| Trust Anchor | Passively | Pre-provisioned via |
| Establishment | retrieved via | operational or root |
| | OIDC Discovery | certificates, with active |
| | | trust granted by CA |
+-------------------+------------------+----------------------------+
Figure 11: Comparison of Security Models between SSO/OAuth and idp-01
7.7. Comparison of Security Models between SSO/OAuth and idp-01
Although IdP operational certificates are formally similar to
subordinate CA certificates (both issued by a CA and used to
authorize external entities), they differ fundamentally in security
role, authorization scope, and trust-transfer mechanism.
* Role: A subordinate CA acts as a "certificate issuer", with X.509
certificates as its authorization output. An IdP (holding an
operational certificate) acts as an "identity verifier", with
one-time JWT tokens as its authorization output.
* Authorization scope: Authorization granted to a subordinate CA is
permanent and broad. Authorization granted to an IdP operational
certificate is temporary and fine-grained (each token includes
idpIdentifier, idp_method, and one-use constraints via jti).
* Compromise impact: Compromise of a subordinate CA private key
equals partial leakage of root CA authority, allowing attackers to
issue arbitrary end-entity certificates. If an IdP operational
Geng, et al. Expires 20 November 2026 [Page 34]
Internet-Draft ACME PK Challenge May 2026
certificate private key is compromised, attackers may only forge
JWT tokens and cannot directly issue X.509 certificates.
Furthermore, the CA performs secondary validation during each
token check (combining identity identifiers and challenge nonces
from orders) and can immediately revoke the operational
certificate to block authorization.
Key Security Recommendations:
* When issuing an IdP operational certificate, the CA *MUST*
explicitly define its intended usage in the certificate: the cA
flag in Basic Constraints *MUST* be FALSE, Key Usage *MUST*
include digitalSignature, and Extended Key Usage (EKU) *MUST*
include id-kp-acmeIdpTokenSigning. The IdP operational
certificate *SHOULD NOT* include any EKUs intended for certificate
issuance (e.g., id-kp-serverAuth or anyExtendedKeyUsage).
* Relying parties *SHOULD NOT* treat IdP operational certificates as
subordinate CA certificates; they *SHOULD* only accept them for
verifying the JWT signature of acmeIdpToken.
* CA operators *SHOULD* clearly specify in the CPS the differences
between IdP operational certificates and subordinate CA
certificates in terms of authorization scope, audit requirements,
and security incident response procedures.
The table below summarizes the differences in key security
attributes:
Geng, et al. Expires 20 November 2026 [Page 35]
Internet-Draft ACME PK Challenge May 2026
+--------------------+--------------------------------------+--------------------------------+
| Attribute | IdP Operational Certificate (Mode 1) | Subordinate CA Certificate |
+--------------------+--------------------------------------+--------------------------------+
| Core Function |Issue identity-verification JWT tokens| Issue X.509 certificates |
| | | |
| Basic Constraints | cA=FALSE | cA=TRUE |
| | | |
| Key EKU | id-kp-acmeIdpToken-Signing | serverAuth, clientAuth |
| | | or anyExtendedKeyUsageE |
| | | |
| Authorized Output | JWT (short-lived, one-time) | X.509 certificate |
| | |(long-lived, chain-transferable)|
| | | |
|May Issue End-Entity| No | Yes |
| Certificates? | | |
| | | |
| Private Key | Attackers may forge identity tokens |Attackers may issue arbitrary |
| Compromise Impact | but cannot issue certificates; |trusted certificates; broad |
| | limited impact scope |impact and high recovery cost |
| | |(CRL/OCSP) |
| | | |
| Typical Lifespan | Recommended ≤ 1 year with automated | Typically 1-10 years with |
| | ACME renewal | manual management |
+--------------------+--------------------------------------+--------------------------------+
Figure 12: Key Security Attribute Differences Between IdP Operational
Certificates and Subordinate CA Certificates
7.8. Comparison with Stand-Alone Use of RFC 9447
There is a clear boundary between the validation objectives of
RFC 9447 [RFC9447] and "idp-01":
* RFC 9447 validates authorization of a specific identifier by an
external authority — for example, a telephone carrier’s right to
allocate a given number.
* "idp-01" validates binding of an applicant’s identity to a public
key by an IdP — focusing on _who the applicant is_ and _which key
they hold_, rather than the source of authorization for a given
identifier.
The two may be combined within a single order: first validate the
identity-public-key binding via "idp-01", then validate identifier
authorization via tkauth-01.
Geng, et al. Expires 20 November 2026 [Page 36]
Internet-Draft ACME PK Challenge May 2026
+---------------------+---------------------------------+---------------------------------+
| Dimension | RFC 9447 (tkauth-01) | idp-01 |
+---------------------+---------------------------------+---------------------------------+
| Validation Target | Identifier authorization source | Identity-public-key binding |
| | | |
| Trust Anchor Source | Identifier-specific external | Operational certificates, |
| | authority (e.g., TNAuthList) | root certificates, or the CA |
| | | itself (corresponding to the |
| | | three deployment modes) |
| | | |
| Public Key Handling | Not applicable | Works with pk-01; |
| | | supports idp-PoP / acme-PoP |
| | | |
| Deployment Mode | Single (external authority) | Three deployment modes |
| | | |
| Relationship with | Orthogonal | Directly associated via the |
| PoP | | synergy matrix (see Section 3.5)|
+---------------------+---------------------------------+---------------------------------+
Figure 13: Comparison between RFC 9447 and idp-01
The semantics of tkauth-01 are that possession of a token issued by
an external authority constitutes possession of the corresponding
identifier. It does not natively support standardized authorization
for IdP identities (operational certificates), branched public-key
sources (CSR / idp-PoP / pk-01), or deployment models where the CA
itself acts as the authority. This document therefore defines the
ICV framework as a standalone challenge type, independent of RFC 9447
in terms of validation objectives and deployment modes.
7.9. Order Binding
"pk-01" [I-D.geng-acme-public-key] cryptographically binds
proof-of-possession of the private key to all bytes of the current
newOrder by including SHA-256(raw_newOrder) in the PoP input. To
align with the security model of "pk-01", this document requires the
IdP to carry back the same hash in the form of the bound_to_order
claim when issuing an acmeIdpToken (see Section 6.3), which the CA
verifies in Step 4 of §6.4.
Multiple defensive layers are provided:
* bound_to_order claim: Cryptographically binds the token to all
bytes of the "newOrder". Any modification to "newOrder" fields
(including the identifiers array) will cause token validation to
fail;
Geng, et al. Expires 20 November 2026 [Page 37]
Internet-Draft ACME PK Challenge May 2026
* One-time consumption of idpIdentifier: The server generates an
idpIdentifier with no less than 128 bits of entropy for each
challenge and marks it as consumed immediately after the challenge
reaches a final state, preventing repeated submission of the same
token;
* One-time use of jti + exp ≤ 5 minutes: Restricts token lifetime,
serving as defense-in-depth in addition to bound_to_order and
one-time consumption of idpIdentifier.
The specific protocol binding for how clients transmit the
raw_newOrder hash to the IdP is defined per idp_method; a typical
implementation submits the hash as an additional parameter to the
IdP’s authentication endpoint. The bound_to_order claim supports two
categories of IdP implementations:
* ACME-context-aware IdPs: Populate the claim directly with the hash
provided by the client;
* Non-ACME-context-aware IdPs: The CA may accept weak binding
(relying solely on one-time jti + idpIdentifier) under policy, but
*SHOULD* explicitly document the security consequences of such
weakening in its CPS.
7.10. Relying-Party Validation Logic for Trust-Domain-Restricted
Certificates
When a relying party receives a certificate containing the
trust_domain_restriction extension, it *SHOULD* perform the following
additional checks in addition to regular PKI path validation:
1. Whether the IdP indicated by idpIdentifier in the certificate
remains in the set trusted by local policy. If trust in the IdP
has been revoked by local policy, the relying party *SHOULD*
reject the certificate.
2. For certificates issued under Mode 1, the relying party *MAY*
check the revocation status of the underlying IdP operational
certificate via OCSP/CRL. If the operational certificate has
been revoked, the relying party *SHOULD* reject downstream
identity certificates issued while the IdP was active.
3. If the certificate contains an idpPolicyURI, the relying party
*MAY* retrieve the IdP’s current policy statement per local
policy and verify whether attributes asserted in the certificate
remain within the IdP’s current authorization scope.
Geng, et al. Expires 20 November 2026 [Page 38]
Internet-Draft ACME PK Challenge May 2026
4. If the certificate contains idpAssertedAttributes, the relying
party *MUST* apply a whitelist filter on attribute types
according to local policy before making authorization decisions
using these attributes. Any attribute type not in the locally
permitted set *SHOULD* be ignored.
The extended checks defined in this section *do not replace* standard
PKI path validation; the two operate cumulatively.
7.10.1. Handling of Critical and Non-Critical Extensions
This document specifies that the trust_domain_restriction extension
is issued as non-critical by default (see §6.5.2). This choice has
two security implications:
* Relying parties that do not recognize the extension will ignore it
and treat the certificate as a regular one — this is the
compatibility trade-off with the existing TLS/S/MIME ecosystem.
By choosing the non-critical setting, the CA accepts the risk that
relying parties may skip trust-domain checks, and *SHOULD*
mitigate this risk via other controls (e.g., restricting
certificate validity periods, monitoring CT logs, limiting the EKU
set).
* Relying parties that recognize the extension *SHOULD* validate it
in accordance with the rules in this section.
When a CA issues this extension as critical, relying parties that do
not support the extension will reject the certificate, providing
fail-closed security guarantees; however, the CA *MUST* verify that
the target relying-party ecosystem supports this extension.
7.10.2. Relationship with Defense-in-Depth
Even if a relying party does not recognize the
trust_domain_restriction extension, the device-level private-key
possession proof (acme-PoP) provided by the "pk-01" synergy branch
still serves as an independent key-binding guarantee: an attacker who
compromises the IdP operational certificate private key cannot
replace the certificate public key. CAs shall take this into account
when evaluating which scenarios require combined ICV + PoP
deployment.
8. IANA Considerations
This document requests IANA to complete the following registrations:
* ACME Identifier Type: Register idp.
Geng, et al. Expires 20 November 2026 [Page 39]
Internet-Draft ACME PK Challenge May 2026
* ACME Validation Method: Register idp-01.
* EKU OID: Register id-kp-acmeIdpTokenSigning (OID to be assigned).
* X.509 PKIX Private Extension OID: Register
id-pe-acme-idp-trust-domain (OID to be assigned, expected under
the PKIX private extension arc; the exact value shall be
determined by IANA in the SMI Security for PKIX Module Identifier
registry).
* ACME Message Fields: Register idpIdentifier, idp_url, idp_method,
deployment_mode, idp_cert_fingerprint, acmeIdpToken.
* acmeIdpToken JWT Claim Names: Register bound_to_order,
idpIdentifier, idp_method, confirmed_public_key. The semantics of
the bound_to_order claim are defined in Sections 6.3, 6.4, and
7.9.
* Error Types (Full URNs):
- urn:ietf:params:acme:error:badIdpToken
- urn:ietf:params:acme:error:rejectedIdpId
- urn:ietf:params:acme:error:idpTimeout
- urn:ietf:params:acme:error:trustDomainRestrictionViolation
* IdP Authentication Method Registry: Initial values are pkic,
opaque, webauthn, internal, device-puf, device-tpm, device-vin,
device-sn. New entries shall be added under the Specification
Required policy ([RFC8126]).
* ACME idpAssertedAttributes Attribute Type Registry: For the
AssertedAttribute.type field of the trust_domain_restriction
extension. No entries are pre-populated in the initial version;
new entries shall be added under the Specification Required
policy, and each entry *MUST* provide the attribute OID, semantic
description, character set, and maximum length. CAs *MUST NOT*
write attributes of unregistered types into certificates.
Geng, et al. Expires 20 November 2026 [Page 40]
Internet-Draft ACME PK Challenge May 2026
9. Appendix A. Same-Domain Trust — Example of the IdP Operational
Certificate Mode (Mode 1, Stand-Alone ICV + CSR)
This appendix addresses the following problem: When an organization
has deployed an identity management system (e.g., enterprise LDAP,
content-platform user system) that is not a CA, how to issue identity
certificates automatically for members of the organization in a
standardized manner.
This scenario falls under a trust chain type referred to as
same-domain trust, applicable to Mode 1 (the IdP operational
certificate model) and the stand-alone ICV + CSR branch. The
involved parties are the CA, the IdP (the organization’s identity
management system, not a CA), and end users.
9.1. Phase 1: IdP Requests an Operational Certificate
The IdP automatically completes operational certificate enrollment
and lifecycle management via an ACME-IDP client. Depending on the
trust level required by the CA, the operational certificate may be of
DV or OV level. The automated enrollment flow is illustrated below
using the OV level as an example:
1. An administrator of the IdP organization first completes
organization validation (pre-validation for OV) on the CA’s
enterprise portal. Upon CA approval, EAB credentials are
generated for this IdP.
2. The IdP deploys the ACME-IDP client, configures the EAB
credentials, and creates an ACME account.
3. Submit a "newOrder" declaring a DNS identifier with profile:
"idp-op-cert-ov" (or "idp-op-cert-dv").
4. The CA returns required challenges according to the profile
requirements; these are automatically completed by the ACME-IDP
client.
5. Submit a CSR, and the CA issues the operational certificate (with
EKU including id-kp-acmeIdpTokenSigning).
For IdPs requiring only a DV-level operational certificate, the
pre-validation in Step 1 may be skipped.
Geng, et al. Expires 20 November 2026 [Page 41]
Internet-Draft ACME PK Challenge May 2026
9.2. Phase 2: User Requests an Identity Certificate
1. The user submits a "newOrder" using an ACME-ICV client on the
device, declaring an idp identifier (e.g., an email address) and
omitting the "pk" identifier (the certificate public key will be
submitted via CSR).
2. The CA returns an "idp-01" challenge with deployment_mode:
"idp-op-cert".
3. The ACME-ICV client interacts with the IdP to complete identity
authentication, and the IdP issues an acmeIdpToken using the
private key of its operational certificate.
4. The ACME-ICV client submits the token; upon successful validation
by the CA, the challenge status becomes valid.
5. The ACME-ICV client submits a standard PKCS#10 CSR during the
finalize phase. The CA extracts the certificate public key from
the CSR and issues an identity certificate (e.g., an S/MIME
certificate).
The certificate public key may differ from the user’s identity public
key maintained on the IdP side — the IdP verifies control over the
identity, while the certificate public key is independently generated
by the user and submitted via the CSR, preserving the user’s
flexibility to use distinct key pairs for different purposes.
10. Appendix B. Same-Domain Trust — Example of CA-Integrated IdP Mode
(Mode 3)
This appendix addresses the following problem: When a CA itself has
built-in user identity management capabilities, how to implement a
fully automated closed-loop workflow of “identity registration →
identity authentication → certificate issuance” on a unified
platform, avoiding separate deployment and management of two
independent systems for the CA and IdP.
This scenario falls under a trust chain type referred to as
*same-domain trust*, applicable to Mode 3 (the CA-integrated IdP
model) and the stand-alone ICV + CSR branch (see Section 3.5). The
involved parties are an internal enterprise CA (acting simultaneously
as the IdP) and enterprise employees.
Geng, et al. Expires 20 November 2026 [Page 42]
Internet-Draft ACME PK Challenge May 2026
10.1. Prerequisites
* The enterprise has deployed an internal CA (e.g., Windows Server
AD CS, HashiCorp Vault PKI, Smallstep CA, etc.) that also manages
user identity registration and authentication.
* The CA has configured its built-in IdP validation endpoint (where
idp_url points to the CA’s own identity authentication service).
* Employees have registered their identities in the user directory
managed by the CA.
* The ACME-ICV client is installed on employee devices.
10.2. Workflow
1. Create a "newOrder": An employee submits a "newOrder" to the CA
via the ACME-ICV client, declaring an "idp" identifier (the
employee’s enterprise identity such as employee ID or email
address) and omitting the "pk" identifier (the certificate public
key will be submitted via CSR).
2. CA returns an "idp-01" challenge: The CA recognizes that the
identifier belongs to a locally managed user and returns an
"idp-01" challenge with deployment_mode: "ca-idp" and idp_method:
"internal".
3. Complete identity authentication: The ACME-ICV client parses the
idp_url (pointing to the CA’s own validation endpoint) and
completes authentication using the internal method.
4. CA issues a token: After verifying the employee’s identity, the
CA issues an acmeIdpToken (or directly completes challenge
validation based on internal state).
5. Submit the token and CSR: The ACME-ICV client submits the token;
upon successful validation by the CA, the challenge status
becomes valid. The employee submits a standard PKCS#10 CSR
during the finalize phase, from which the CA extracts the
certificate public key and issues an identity certificate.
Geng, et al. Expires 20 November 2026 [Page 43]
Internet-Draft ACME PK Challenge May 2026
10.3. Scenario Value
This scenario demonstrates the simplicity and efficiency of the ICV
framework under the deployment model where the CA and IdP are
unified. Compared with traditional solutions requiring separate
deployment and management of CA and IdP, Mode 3 significantly reduces
the infrastructure complexity of enterprise identity certificate
management. This model aligns with industry practices of products
such as Windows Server AD CS, HashiCorp Vault, and Foxpass Cloud PKI.
11. Appendix C. Same-Domain / Cross-Domain Trust — Enterprise PKI
Bridging Scenario (Mode 2)
This appendix addresses the problem: when two organizations each
operate their own private CAs and need to automatically issue
certificates for members of the other organization to enable secure
communication interoperability, how to leverage existing PKI
infrastructure for automated cross-organizational certificate
provisioning.
This scenario falls under Type-1 or Type-2 trust chains (same-domain
or cross-domain trust) and applies to Mode 2 (the PKI internal-domain
mutual-recognition model).
11.1. Scenario 1: Same-Domain Trust
Boundary Note: When an organization operates a single internal CA
that also performs identity validation functions, the “CA acting as
IdP” case actually falls under Mode 3 (CA-integrated IdP), whose full
workflow is provided in Appendix B. This section references it as a
boundary case for Mode 2 to illustrate that the cross-domain bridging
approach described in this appendix degenerates into Mode 3 for
strictly single-CA organizations with embedded identity services.
The degenerated workflow is as follows: An employee submits a
"newOrder" via the ACME-ICV client, the CA returns an "idp-01"
challenge (with idp_method set to internal), and after successful
validation, the employee submits the certificate public key via a CSR
during the finalize phase. The entire workflow is completed within
the enterprise boundary.
If an organization operates multiple internal CAs (e.g., a root CA
with subordinate CAs, or private CAs for different departments), this
constitutes the genuine same-domain variant of Mode 2 described later
in this section. Handling is identical to the cross-domain case
(C.2), except that secure channels for pre-configuring trust anchors
are established internally within the organization without
out-of-band coordination.
Geng, et al. Expires 20 November 2026 [Page 44]
Internet-Draft ACME PK Challenge May 2026
11.2. Scenario 2: Cross-Domain Trust
Enterprises A and B engage in joint research and development, and
Enterprise A needs to issue short-lived client certificates for Bob,
an employee of Enterprise B. Both parties have exchanged root
certificates via out-of-band channels.
1. Bob submits a "newOrder" via the ACME-ICV client (including
enterprise identifiers; this scenario uses the combined ICV + PoP
approach and also declares a "pk" identifier).
2. The CA of Enterprise A returns an "idp-01" challenge with
deployment_mode: "pki-intra", where idp_url points to the CA of
Enterprise B.
3. The ACME-ICV client assists Bob in signing a submission to
Enterprise B’s CA using the private key of his enterprise
identity certificate. After validation, Enterprise B’s CA issues
an acmeIdpToken (with a pairwise pseudonym as the sub claim).
4. Enterprise A’s CA validates the token using Enterprise B’s root
certificate, verifies proof-of-possession for the certificate
public key per "pk-01", and finally issues the short-lived client
certificate.
Multi-party federations may implement automated cross-issuance by
exchanging root certificates and configuring trust anchors.
12. Appendix D. Cross-Domain Trust — E2EE Meeting Certificate
Provisioning (Mode 1 + Mode 2)
This appendix addresses the following problem: In
cross-organizational end-to-end encrypted meeting scenarios, external
participants need short-lived admission certificates issued by the
host CA to join group key agreement. The organizations of external
participants may have pre-established PKI mutual trust with the host,
or may share no trust relationship at all.
This scenario falls under Type-2 trust chains (cross-domain trust).
Mode 2 and Mode 1 are adopted respectively depending on whether
pre-configured root-certificate mutual trust exists between the host
and the organizations of external participants.
Geng, et al. Expires 20 November 2026 [Page 45]
Internet-Draft ACME PK Challenge May 2026
12.1. Case 1: Pre-established Root-Certificate Mutual Trust Between
Both Enterprises (Mode 2)
The CAs of Enterprise A and Enterprise B have exchanged root
certificates via out-of-band channels. Employees of Enterprise B
hold identity certificates issued by Enterprise B’s CA. This case
adopts the combined ICV + PoP branch (see Section 3.5): external
participants complete the "idp-01" challenge using identity
certificates issued by Enterprise B’s CA, and perform "pk-01"
validation via the "pk" identifier declared within the same order.
The CA of Enterprise A validates the token using the pre-configured
root certificate of Enterprise B and issues short-lived meeting
admission certificates. The remaining steps of the workflow are
consistent with Appendix C.2.
12.2. Case 2: No Pre-established Root-Certificate Mutual Trust Between
Enterprises — Guest Mode (Mode 1)
No pre-configured CA root-certificate trust relationship exists
between Enterprise A and Enterprise B. An employee of Enterprise B
is invited as a guest to temporarily join an external meeting hosted
by Enterprise A. This scenario demonstrates the deployment
flexibility of the ICV framework in the absence of pre-established
PKI trust relationships, adopting the stand-alone ICV trust with the
idp-PoP branch (see Section 3.5): Enterprise A does not need to
pre-trust Enterprise B’s CA; it only needs to pre-register a
temporary guest account on its own IdP to automatically issue a
short-lived certificate valid for this meeting to the guest.
As a concrete implementation example, identity authentication between
the guest and Enterprise A’s IdP may use the OPAQUE protocol
([RFC9807]):
* Enterprise A’s IdP supports user registration and authentication
via the OPAQUE protocol.
* Temporary guest accounts created by the meeting organizer are
registered using OPAQUE; the guest’s temporary account credential
(passphrase) is delivered over an out-of-band secure channel.
* Enterprise A’s IdP specifies idp_method: opaque in the idp-01
challenge.
* The guest’s ACME-ICV client performs the OPAQUE protocol with the
IdP to complete authentication. During the AKE phase, the IdP
confirms the guest holds the registered private key (idp-PoP) and
issues an acmeIdpToken.
Geng, et al. Expires 20 November 2026 [Page 46]
Internet-Draft ACME PK Challenge May 2026
Key steps:
1. Pre-registration of temporary account by meeting organizer: The
temporary account is valid only for the duration of this meeting
and expires automatically upon meeting conclusion. The temporary
login passphrase is sent to the guest via an out-of-band channel
such as encrypted email.
2. Initial guest access: The guest connects to Enterprise A’s
meeting server using temporary account credentials via the
ACME-ICV client, with access restricted only to the meeting
waiting area at this stage.
3. CA returns "idp-01" challenge: Enterprise A’s CA returns an
"idp-01" challenge with deployment_mode: "idp-op-cert" and
idp_method: "opaque".
4. Guest performs OPAQUE authentication: After verifying the guest
holds the registered private key during the AKE phase, the IdP
issues an acmeIdpToken (with a pairwise pseudonym as the sub
claim) using its operational certificate private key.
5. Certificate issuance and meeting admission: The CA issues a
short-lived admission certificate after validating the token.
The guest reconnects to the meeting using the new certificate and
completes E2EE group key agreement.
The entire process has no dependencies on Enterprise B’s
infrastructure. The ACME-ICV and ACME-IDP clients operate
independently to deliver full automation for cross-domain guest
scenarios. The OPAQUE implementation is particularly suited to use
cases requiring high passphrase security: even if the IdP is
compromised, attackers cannot obtain guest passphrases for
credential-stuffing attacks.
13. Appendix E. Cross-Domain Trust — Automated C2PA Certificate
Issuance (Mode 1 / Mode 2 / Mode 3)
This appendix addresses the problem that within the C2PA (Coalition
for Content Provenance and Authenticity) content-credentialing
ecosystem, individual creators and organizational entities require
signing certificates issued by CAs listed in the C2PA Trust List.
Current certificate issuance workflows rely on manual identity
vetting and cannot be automated for large-scale content production
deployments.
Geng, et al. Expires 20 November 2026 [Page 47]
Internet-Draft ACME PK Challenge May 2026
Depending on the creator’s identity type and the PKI deployment
status of their affiliated organization, one of the three deployment
modes may be applied to this scenario.
13.1. Requirements Description
A C2PA Manifest binds content to the signer’s identity via digital
signatures. Verifiers confirm content provenance by checking whether
the signing certificate is issued by a CA included in the C2PA Trust
List.
Applicants fall into two categories: individual creators (e.g.,
photographers, journalists) whose identities are typically verified
on content platforms; and organizational entities (e.g., news
agencies, content platforms, brand owners) that usually hold
organizational certificates issued by enterprise CAs.
13.2. Applicability of the Three Deployment Modes
* Mode 1 (IdP Operational Certificate Model): Applicable to
individual creator scenarios. A content platform obtains an
operational certificate from a C2PA-compliant CA to act as an IdP
via an ACME-IDP client. Creators complete authentication with the
platform IdP using an ACME-ICV client to obtain a token, after
which the CA issues a C2PA certificate.
* Mode 2 (PKI Intra-Domain Mutual-Recognition Model): Applicable to
organizational entity scenarios. The enterprise CA root
certificate is added as a trust anchor to the C2PA-compliant CA.
Employees complete the "idp-01" challenge using their enterprise
certificates.
* Mode 3 (CA-Integrated IdP Model): Applicable to scenarios where
the CA platform itself manages creator identities and certificate
lifecycles.
CAs embed certificate policy OIDs in compliance with C2PA
specifications. Bulk issuance can be fully automated via enterprise
CA endpoints.
13.3. Deployment Recommendations
Geng, et al. Expires 20 November 2026 [Page 48]
Internet-Draft ACME PK Challenge May 2026
+-------------------------+--------+------------------------------+
| Scenario | Mode | IdP Role |
+-------------------------+--------+------------------------------+
| News agency for | Mode 2 | Agency enterprise CA |
| its journalists | or 3 | |
| | | |
| Photo agency for | Mode 1 | Agency authentication system |
| contracted photographers| or 3 | |
| | | |
| Social platform for | Mode 1 | Platform identity system |
| verified users | or 3 | |
| | | |
| Government agency for | Mode 2 | Government PKI |
| civil servants | or 3 | |
+-------------------------+--------+------------------------------+
Figure 14: Deployment Recommendations for C2PA Scenarios
14. Appendix F. Cross-Domain Trust — Federated Trust Scenarios (Mode 2
+ Federated Trust Model)
This appendix addresses the problem of how to leverage federated
trust infrastructure to reduce coordination costs when multiple
independent organizations require automated cross-organizational
identity certificate provisioning via a multilateral trust framework,
rather than signing bilateral mutual-recognition agreements
one-by-one.
This scenario falls under Type-3 trust chains (federated trust).
Built upon Mode 2 (the PKI intra-domain mutual-recognition model), it
incorporates a federated trust model and adopts the combined
ICV + PoP branch to guarantee ownership of the certificate public key
during cross-domain certificate issuance (see Section 3.5).
14.1. Scenario Description
Multiple research institutions form a joint consortium via the
eduGAIN federation. eduGAIN is an international service connecting
global research communities and higher-education identity
federations, covering more than 80 participating federations and
linking over 8 000 identity and service providers. The consortium
requires CAs of all member institutions to issue short-lived access
certificates for researchers from other member institutions.
Geng, et al. Expires 20 November 2026 [Page 49]
Internet-Draft ACME PK Challenge May 2026
The federated trust chain is established under OpenID Federation 1.0.
Layered collaboration is formed between "idp-01" (the validation
action layer) and OpenID Federation (the trust model layer): the
federated trust chain addresses “how to trust an IdP”, while "idp-01"
addresses “how to perform identity-to-public-key binding validation”.
14.2. Workflow
1. Researcher Alice (from Institution A) submits a "newOrder" to the
CA of Institution B via the ACME-ICV client.
2. The CA of Institution B verifies the identity of Institution A’s
IdP through the OpenID Federation trust chain and retrieves the
token-signing public key.
3. The CA returns an "idp-01" challenge with idp_url pointing to
Institution A’s IdP.
4. The ACME-ICV client assists Alice in completing authentication to
obtain a token (with a pairwise pseudonym as the sub claim).
5. The CA of Institution B validates the token and issues a
short-lived access certificate.
15. Appendix G. Stand-Alone ICV Trust with idp-PoP — Temporary
Certificates for Public Device Scenarios
This appendix addresses the problem of how users can securely and
conveniently obtain short-lived identity certificates for untrusted
public devices (e.g., conference room terminals, shared workstations)
when participating in secure communications, without pre-provisioning
any key material or certificates, while minimizing required user
interactions.
This appendix presents a representative application of the
stand-alone ICV (CA-trusted idp-PoP) branch. It falls under Type-1
trust chains (same-domain trust) and adopts Mode 1 (the IdP
operational certificate model).
15.1. Participants and Prerequisites
Participants: a CA, an IdP (holding an operational certificate via an
ACME-IDP client), an end-user, and a public device (with an ACME-ICV
client installed).
Geng, et al. Expires 20 November 2026 [Page 50]
Internet-Draft ACME PK Challenge May 2026
Prerequisites: The user has registered an OPAQUE account with the IdP
and securely deposited an ephemeral public-private key pair encrypted
at the IdP. The IdP has obtained an operational certificate from the
CA, and the CA trusts the IdP’s authentication results for OPAQUE
accounts as well as the idp-PoP proof.
15.2. Workflow
1. User logs into the public device and retrieves the ephemeral key
pair: The user enters their OPAQUE account passphrase via the
ACME-ICV client on the public device. The client performs the
OPAQUE protocol with the IdP to complete authentication, securely
retrieves the encrypted ephemeral public-private key pair
deposited with the IdP, and decrypts it using the passphrase to
obtain the ephemeral private key.
2. Create a "newOrder": The client submits a "newOrder" to the CA,
declaring only the idp identifier (set to the user’s OPAQUE
identity) and omitting the "pk" identifier.
3. CA returns an "idp-01" challenge with deployment_mode:
"idp-op-cert" and idp_method: "opaque".
4. Complete identity authentication: The client forwards challenge
information to the IdP. The IdP issues an acmeIdpToken using the
private key of its operational certificate. The token contains a
confirmed_public_key claim whose value is the base64url-encoded
SPKI of the ephemeral public key — a public key known to the IdP
from OPAQUE registration, for which the IdP verifies user
possession of the corresponding private key during this
authentication.
5. Submit the token: The client POSTs the acmeIdpToken to the
challenge URL.
6. CA validates and issues the certificate: The CA validates the
token signature and content. As the CA is configured to trust
OPAQUE-based idp-PoP and no "pk" identifier is present in the
order, the CA applies the stand-alone ICV (idp-PoP-trusted)
branch. It directly extracts the ephemeral public key from
confirmed_public_key as the certificate public key, issues a
short-lived device certificate, and sets the subject to the
pairwise pseudonym contained in the token.
Geng, et al. Expires 20 November 2026 [Page 51]
Internet-Draft ACME PK Challenge May 2026
7. Use the temporary certificate: The public device now holds the
ephemeral private key and its corresponding short-lived device
certificate, enabling access to the enterprise E2EE video
conferencing system. Upon meeting conclusion, the certificate
expires naturally, and the ephemeral key pair on the public
device can be securely erased.
The entire workflow requires the user to remember only a single
passphrase.
16. Appendix H. Enterprise Intranet Device Proxy Scenario (ACME-ICV
Proxy Mode)
This appendix addresses the problem of enabling automated identity
certificate issuance using the ICV framework when enterprise endpoint
devices reside on an intranet behind a firewall and cannot directly
access external public CAs. This represents a typical scenario where
an IdP acting as a Registration Authority (RA) fosters new business
models within the PKI/CA ecosystem — the IdP may serve as both an
identity-verification gateway and a certificate enrollment proxy.
16.1. Scenario Description
An enterprise internal network hosts numerous devices (e.g.,
workstations, servers, IoT devices) located behind firewalls or NAT
gateways. The enterprise IdP acts as an identity management gateway
deployed at the enterprise network perimeter (e.g., in the DMZ), with
connectivity to both the intranet and the public internet.
The IdP deploys an ACME-ICV proxy client that serves as a unified
certificate enrollment representative for enterprise intranet
devices. The proxy client itself has obtained RA authorization from
the CA via an IdP operational certificate. Intranet devices initiate
local certificate requests to the IdP proxy. After verifying device
identities, the IdP proxy completes the idp-01 challenge with the
external CA on behalf of the devices.
16.2. Proxy-Mode Architecture
Involved components:
* External CA: A public or externally trusted CA.
* Enterprise IdP (proxy node): Deployed in the DMZ, holding an
operational certificate issued by the CA, and running an ACME-ICV
proxy client.
Geng, et al. Expires 20 November 2026 [Page 52]
Internet-Draft ACME PK Challenge May 2026
* Intranet devices: End-user devices within the enterprise intranet
that cannot directly access the external CA.
The architectural relationships are as follows:
[External CA] (Internet)
|
| ACME (idp-01 challenge + token validation)
|
[Enterprise IdP / Proxy Node] (DMZ)
/ | \
/ | \
/ (Internal | (Internal \ (Internal API)
/ API) | API) \
/ | \
[Device A] [Device B] [Device C] (Intranet)
16.3. Proxy Workflow
Taking an intranet IoT sensor (Device X) requesting an identity
certificate as an example:
1. Device X initiates a local request: It generates a public-private
key pair, constructs a local certificate request containing a
device identifier (e.g., serial number SN:XYZ123) and the
public-key SPKI, and sends the request to the IdP proxy node via
an internal API.
2. The IdP proxy verifies the device identity: Validation is
performed in accordance with enterprise policies (based on
pre-shared keys, MAC-address binding, or device registration
records in the enterprise CMDB).
3. The IdP proxy executes the external ACME-ICV workflow:
a. As an ACME-ICV client, it submits a "newOrder" to the
external CA, declaring the idp identifier set to Device X’s
pairwise pseudonym.
b. The CA returns an "idp-01" challenge with deployment_mode:
"idp-op-cert", where idp_method is selected according to the
device type (e.g., device-sn).
c. The IdP proxy encapsulates Device X’s authentication result
into an acmeIdpToken and signs it using the private key of its
operational certificate. The token contains a
confirmed_public_key claim whose value is the base64url-encoded
SPKI of Device X’s public key.
Geng, et al. Expires 20 November 2026 [Page 53]
Internet-Draft ACME PK Challenge May 2026
d. The IdP proxy POSTs the token to the CA challenge URL.
4. The CA validates and issues the certificate: The CA validates the
acmeIdpToken (chaining back to the IdP operational certificate)
and trusts the IdP’s device authentication result. Since no "pk"
identifier is declared in the order, the CA applies the
stand-alone ICV (idp-PoP-trusted) branch, directly extracts
Device X’s public key from confirmed_public_key, and issues an
end-entity certificate.
5. Certificate delivered to the intranet device: The CA returns the
certificate to the IdP proxy, which forwards it to Device X.
16.4. Security Considerations and Limitations
* The IdP proxy must implement strong authentication mechanisms to
prevent adversaries from impersonating intranet devices and
requesting certificates from the proxy. Mutual authentication
using pre-shared client certificates or API keys is recommended
between intranet devices and the proxy.
* The private key for the IdP proxy’s operational certificate *MUST*
be strictly protected (use of an HSM or secrets management service
is recommended).
* The proxy mode introduces an additional trust boundary: the CA
trusts the device authentication results from the IdP proxy, while
the IdP proxy trusts identity claims from intranet devices.
Enterprises *SHOULD* enforce rigorous intranet device registration
and validation policies, and regularly audit proxy logs.
* This mode is suitable for enterprise environments requiring
centralized certificate lifecycle management, especially for
large-scale IoT/OT deployments where devices cannot directly
access the public internet.
17. Appendix I. Cross-Domain Trust — sigstore Code-Signing Scenario
(Mode 1 + OIDC-Bridged IdP)
This appendix addresses the following problem: In modern software
supply chains, manual issuance, long-term private-key custody, and
revocation workflows for code-signing certificates severely restrict
automated deployment. Most developers already have verifiable
identities established via public OIDC providers such as GitHub,
Google, and Microsoft, yet lack a standardized path to convert such
identities into X.509 certificates acceptable within the code-signing
ecosystem.
Geng, et al. Expires 20 November 2026 [Page 54]
Internet-Draft ACME PK Challenge May 2026
This scenario falls under Type-2 trust chains (cross-domain trust)
and adopts the OIDC-bridged variant of Mode 1 (the IdP operational
certificate model). This appendix aligns with sigstore [SIGSTORE]’s
“keyless signing” workflow in terms of motivation and role
partitioning; the detailed interaction flow is consistent with
Section 5.1 and Appendix D.2 and is therefore not elaborated further
here.
17.1. Motivation
Pain points of traditional code-signing deployments:
* Certificate issuance relies on manual organizational validation
and cannot be self-serviced within CI/CD pipelines;
* Signing private keys require long-term secure storage (HSM/smart
cards), imposing heavy management overhead;
* Developer identities across projects and organizations are
difficult to reuse in traditional PKI.
Industry practice with sigstore has demonstrated that converting
developers’ OIDC identities into short-lived code-signing
certificates, combined with transparency logs recording certificate
validity at signing time, enables a “zero long-term key management”
code-signing workflow for large-scale software supply chain
scenarios. This approach has been adopted by major ecosystems
including Kubernetes, npm, and PyPI. The goal of this appendix is to
incorporate this industry practice into the ACME standardization
path, so that automated issuance of code-signing certificates can be
achieved under the unified ICV framework, rather than relying on
proprietary interfaces of specific implementations.
17.2. Alignment with This Draft
The existing sigstore architecture naturally aligns with the ICV
framework of this draft in terms of roles and protocol interfaces:
* Fulcio (the CA issuing short-lived code-signing certificates) =
ACME Server (CA);
* Public OIDC providers (GitHub, Google, Microsoft, etc.) =
third-party IdPs;
* Signing tools such as cosign = ACME-ICV clients;
* Developer OIDC identities (the combination of iss + sub) map to
the value field of the "idp" identifier in URI form.
Geng, et al. Expires 20 November 2026 [Page 55]
Internet-Draft ACME PK Challenge May 2026
Since public OIDC providers do not hold operational certificates
issued by the CA (lacking the id-kp-acmeIdpTokenSigning EKU), this
scenario adopts the OIDC-bridged IdP deployment pattern: the CA
itself or a trusted operator deploys an ACME-IDP client together with
an OIDC bridge. The bridge holds an operational certificate issued
by the CA and re-signs using an acmeIdpToken after validating
upstream OIDC ID Tokens. The recommended value for idp_method is
"oidc" (pending IANA registration), and the bound_to_order claim is
carried via the standard OIDC nonce parameter (see Section 7.9).
This pattern is consistent with the “SAML/OIDC-based IdP integration”
described in Section 6.7.2.
The certificate lifecycle is recommended to follow sigstore’s
short-lived certificate practice (ranging from minutes to hours) and
be deployed in conjunction with upstream transparency logs (e.g.,
sigstore Rekor). Transparency logs are a complementary mechanism
outside the scope of this draft and are orthogonal to the
trust_domain_restriction extension: the former addresses evidence
preservation for “certificate validity at signing time”, while the
latter addresses runtime recognition of the IdP trust domain by
relying parties.
17.3. Simplified Workflow
Participants: a CA, an OIDC-bridged IdP (deployed by the CA itself or
a trusted operator, holding an operational certificate issued by the
CA), public OIDC providers (GitHub, Google, Microsoft, etc.),
developers, and their CI pipelines. This scenario applies the
stand-alone ICV + CSR branch (see Section 3.5).
1. CI-triggered signing: A pipeline (e.g., GitHub Actions, GitLab
CI) initiates a signing task. An ACME-ICV client (a cosign-style
signing tool) retrieves the upstream OIDC ID Token from the
runtime environment.
2. Create a "newOrder": The client generates an ephemeral signing
key pair and submits a "newOrder" to the CA, declaring the "idp"
identifier with a value formatted as a URI:
oidc:<issuer>#<subject>.
3. CA returns a challenge: with deployment_mode: "idp-op-cert",
idp_method: "oidc", and idp_url pointing to the OIDC-bridged IdP
endpoint.
4. Bridged IdP validates identity: The client submits the ID Token
to the bridged IdP, where the nonce field carries
base64url(SHA-256(raw_newOrder)). After validating the upstream
token’s signature and the iss/aud/exp/nonce claims via the OIDC
Geng, et al. Expires 20 November 2026 [Page 56]
Internet-Draft ACME PK Challenge May 2026
JWKS, the bridged IdP issues an acmeIdpToken using the private
key of its operational certificate, with a pairwise pseudonym
recommended for the sub claim.
5. Token submission and certificate issuance: The client POSTs the
acmeIdpToken to the challenge URL. Upon successful validation by
the CA, the client submits a PKCS#10 CSR during the finalize
phase, and the CA issues a short-lived code-signing certificate.
6. (Optional) Transparency log registration: The CA or client
submits the certificate and signing event to an external
transparency log (e.g., sigstore Rekor) to preserve evidence of
certificate validity at signing time.
The entire workflow is transparent to developers: developers only
need an OIDC identity and do not manage any long-term signing private
keys. Ephemeral key pairs are generated per CI job and naturally
expire alongside the certificate.
17.4. Value
This appendix demonstrates the capability of the ICV framework to
build a standardized bridge between public OIDC identities and
enterprise-grade PKI: developers do not need additional credentials,
upstream OIDC IdPs require no modifications to their authentication
protocols, and CAs retain final issuance authority. Aligned with
real-world deployment experience of sigstore, this mode provides a
standardized path for integrating “zero long-term key management”
code-signing workflows into the ACME ecosystem, and together with
Appendix E (C2PA), achieves full coverage of both content-signing and
code-signing scenarios.
18. Acknowledgements
The motivation and design of this document have benefited from
exploratory work by numerous experts in the ACME Working Group on
non-DCV authentication approaches over time.
The authors thank [I-D.biggs-acme-sso] for pioneering the concept of
third-party identity provider participation in ACME validation.
Thanks are extended to [RFC8823] for contributions to defining email
identifiers and enabling automated issuance of end-user S/MIME
certificates. We acknowledge [I-D.ietf-acme-client] for first
identifying automation requirements for end-user, device, and
code-signing certificates. Appreciation goes to
[I-D.ietf-acme-telephone] for exploring the applicability of
non-domain identifiers (such as telephone numbers) validated via
external authoritative entities. We thank
Geng, et al. Expires 20 November 2026 [Page 57]
Internet-Draft ACME PK Challenge May 2026
[I-D.ietf-acme-device-attest] for leveraging hardware roots of trust
to verify device identities, providing key references for device
authentication scenarios. Finally, gratitude is given to [RFC9447]
and [I-D.ietf-acme-openid-federation] for serving as core references
in the design of the generic authoritative token challenge framework
and multi-layered trust-chain mechanisms.
The authors also thank all members of the ACME Working Group for
their valuable feedback during discussions on ACME identity-related
proposals.
19. References
19.1. Normative References
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC8823] Melnikov, A., "Extensions to Automatic Certificate
Management Environment for End-User S/MIME Certificates",
RFC 8823, DOI 10.17487/RFC8823, April 2021,
<https://www.rfc-editor.org/info/rfc8823>.
[RFC9447] Peterson, J., Barnes, M., Hancock, D., and C. Wendt,
"Automated Certificate Management Environment (ACME)
Challenges Using an Authority Token", RFC 9447,
DOI 10.17487/RFC9447, September 2023,
<https://www.rfc-editor.org/info/rfc9447>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/info/rfc5480>.
Geng, et al. Expires 20 November 2026 [Page 58]
Internet-Draft ACME PK Challenge May 2026
[RFC9807] Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The
OPAQUE Augmented Password-Authenticated Key Exchange
(aPAKE) Protocol", RFC 9807, DOI 10.17487/RFC9807, July
2025, <https://www.rfc-editor.org/info/rfc9807>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
19.2. Informative References
[I-D.geng-acme-public-key]
Geng, F., Wu, P., Xia, L., and C. 陈鑫, "Automated
Certificate Management Environment (ACME) Extension for
Public Key Challenges", Work in Progress, Internet-Draft,
draft-geng-acme-public-key-06, 17 April 2026,
<https://datatracker.ietf.org/doc/html/draft-geng-acme-
public-key-06>.
[I-D.ietf-acme-telephone]
Peterson, J. and R. Barnes, "ACME Identifiers and
Challenges for Telephone Numbers", Work in Progress,
Internet-Draft, draft-ietf-acme-telephone-01, 30 October
2017, <https://datatracker.ietf.org/doc/html/draft-ietf-
acme-telephone-01>.
[I-D.biggs-acme-sso]
Biggs, A., Barnes, R., and R. Moynihan, "Automated
Certificate Management Environment (ACME) Extension for
Single Sign On Challenges", Work in Progress, Internet-
Draft, draft-biggs-acme-sso-01, 8 April 2021,
<https://datatracker.ietf.org/doc/html/draft-biggs-acme-
sso-01>.
[I-D.ietf-acme-client]
Moriarty, K., "ACME End User Client and Code Signing
Certificates", Work in Progress, Internet-Draft, draft-
Geng, et al. Expires 20 November 2026 [Page 59]
Internet-Draft ACME PK Challenge May 2026
ietf-acme-client-14, 11 August 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-acme-
client-14>.
[I-D.ietf-acme-openid-federation]
De Marco, G., Pitman, B., Geoghegan, T., Cook, D., and J.
Jones, "Automatic Certificate Management Environment
(ACME) with OpenID Federation 1.0", Work in Progress,
Internet-Draft, draft-ietf-acme-openid-federation-00, 16
December 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-acme-openid-federation-00>.
[I-D.ietf-acme-device-attest]
Weeks, B., Mallaya, G., Rajala, S., Bonnell, C., and R.
Hurst, "Automated Certificate Management Environment
(ACME) Device Attestation Extension", Work in Progress,
Internet-Draft, draft-ietf-acme-device-attest-04, 5 May
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
acme-device-attest-04>.
[I-D.ietf-acme-profiles]
Gable, A., "Automated Certificate Management Environment
(ACME) Profiles Extension", Work in Progress, Internet-
Draft, draft-ietf-acme-profiles-01, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-acme-
profiles-01>.
[SIGSTORE] Sigstore Project, "sigstore: A new standard for signing,
verifying and protecting software", October 2021.
[WebAuthn] Balfanz, D. and et. al., "Web Authentication: An API for
accessing Public Key Credentials Level 2", April 2021.
Authors' Addresses
Feng Geng
Huawei Technologies
Email: gengfeng@huawei.com
Panyu Wu
Huawei Technologies
Email: wupanyu3@huawei.com
Xin Chen
TrustAsia
Email: palos.chen@trustasia.com
Geng, et al. Expires 20 November 2026 [Page 60]