Automated Certificate Management Environment Working Group F. Geng Internet-Draft P. Wu Intended status: Informational G. Wang Expires: 21 January 2027 Huawei Technologies X. Chen TrustAsia 20 July 2026 ACME STAR Extension for SM2 Dual-Certificate Automated Key Rotation draft-geng-acme-sm2dualcert-rotation-00 Abstract The SM2 dual-certificate system, specified in [GMT.0034-2014], employs a dual-certificate architecture in which each entity holds both a signature certificate and an encryption certificate. The encryption private key is generated and escrowed by the Key Management Center (KMC). This document defines an *ACME Profile* that adapts the core protocol of [RFC8555] to the specific deployment scenario of SM2 dual- certificate management in the ShangMi (SM) ecosystem. Building upon the dual-certificate foundation framework defined in [I-D.geng-acme- sm2dualcert-extension], this document defines a STAR extension for the ACME protocol that enables *synchronized short-term automatic renewal* of SM2 dual certificates. The signature certificate follows [RFC8739] (ACME STAR) for automatic renewal with the same key pair; the encryption certificate achieves automated key rotation with a fresh key pair per epoch based on *Asynchronous Remote Key Generation (ARKG)* [Frymann2020]. This extension establishes a *unified ARKG seed chain key derivation system*: the KMC holds a seed seed_kmc and derives all encryption certificate key pairs (pk_i, sk_i) for all epochs via the ARKG algorithm, enabling stateless, lightweight KMC operations. On this basis, this extension provides *two private key delivery modes*: * *Mode A (ARKG Envelope Delivery)*: delivers sk_i to the client via a digital envelope, fully inheriting the envelope mechanism of the base framework. * *Mode B (ARKG Offline DH Derivation)*: the initial private key is obtained via envelope delivery; subsequent private keys are derived offline by the client, providing key insulation security properties. Geng, et al. Expires 21 January 2027 [Page 1] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 Both modes share the same ARKG cryptographic infrastructure, differing only in the final delivery mechanism of the private key. Deployers may choose according to their requirements, with full compatibility and coexistence achieved through ACME directory object negotiation. *Document Positioning*: This document is intended for the *specific SM ecosystem* as a practical guide and interoperability reference, and does not seek to become a general Internet standard. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 21 January 2027. 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 1.3. Solution Overview . . . . . . . . . . . . . . . . . . . . 6 1.4. Scope and Positioning . . . . . . . . . . . . . . . . . . 7 Geng, et al. Expires 21 January 2027 [Page 2] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 1.5. Relationship to Existing Work . . . . . . . . . . . . . . 8 1.6. Relationship to Delegated Credential Scenarios . . . . . 9 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Unified ARKG Key Derivation System . . . . . . . . . . . . . 11 3.1. ARKG SM Cryptographic Suite . . . . . . . . . . . . . . . 11 3.2. Seed Chain and Key Derivation . . . . . . . . . . . . . . 12 3.3. Security Properties . . . . . . . . . . . . . . . . . . . 14 4. Encryption Private Key Delivery Modes . . . . . . . . . . . . 14 4.1. Mode A: ARKG Envelope Delivery (Default) . . . . . . . . 14 4.2. Mode B: ARKG Offline DH Derivation (OPTIONAL Enhancement) . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Mode Relationship and Migration . . . . . . . . . . . . . 18 4.4. Encryption Private Key Delivery Mode Selection Guide . . 18 5. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Phase One: Bootstrap . . . . . . . . . . . . . . . . . . 19 5.2. Phase Two: Auto Renewal . . . . . . . . . . . . . . . . . 21 5.3. Phase Three: Certificate Access . . . . . . . . . . . . . 21 6. ACME Protocol Extensions . . . . . . . . . . . . . . . . . . 21 6.1. Directory Object Extensions . . . . . . . . . . . . . . . 21 6.2. Creation of Encryption Certificate Orders . . . . . . . . 23 6.3. Key Rotation State Resource and State Transitions . . . . 25 6.4. Certificate and Private Key Retrieval . . . . . . . . . . 27 6.5. Key Rotation Management . . . . . . . . . . . . . . . . . 28 6.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 28 7. Auditable Recovery and Proof . . . . . . . . . . . . . . . . 31 7.1. Authorized Audit Procedure . . . . . . . . . . . . . . . 31 7.2. Post-hoc Audit Proof Based on Certificate Transparency Logs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8.1. Key Management Security . . . . . . . . . . . . . . . . . 32 8.2. Protocol and Communication Security . . . . . . . . . . . 32 8.3. Cryptographic Security . . . . . . . . . . . . . . . . . 32 8.4. Compliance and Coordination . . . . . . . . . . . . . . . 33 8.5. Post-Quantum Cryptography Preparedness . . . . . . . . . 33 9. Design Considerations . . . . . . . . . . . . . . . . . . . . 35 9.1. Independent Key Rotation vs. Synchronization with Signature Certificate . . . . . . . . . . . . . . . . . . . . . . . 35 9.2. Two Independent Orders vs. Single Bundle Order . . . . . 35 9.3. Key Rotation State Resource vs. Order Extension Fields . 36 9.4. Envelope Delivery vs. Offline DH Derivation . . . . . . . 36 9.5. Seed Chain Derivation vs. Direct Private Key Storage . . 37 9.6. Cancellation Semantics Alignment with STAR vs. Custom . . 37 9.7. Key Insulation as an Additional Security Property for Encryption Certificates . . . . . . . . . . . . . . . . . 38 10. Future Considerations . . . . . . . . . . . . . . . . . . . . 38 10.1. PQC Migration and Algorithm Extension . . . . . . . . . 38 10.2. KMC Performance Planning for Large-Scale Deployments . . 39 10.3. KMC Public Key Rotation Mechanism . . . . . . . . . . . 39 Geng, et al. Expires 21 January 2027 [Page 3] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 10.4. Integration with ARI . . . . . . . . . . . . . . . . . . 40 11. IANA and SM Ecosystem Deployment Considerations . . . . . . . 40 11.1. OID Allocation Recommendations . . . . . . . . . . . . . 40 11.2. ACME Registry Entries . . . . . . . . . . . . . . . . . 40 11.3. Algorithm Identifier Registration . . . . . . . . . . . 41 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 12.1. Normative References . . . . . . . . . . . . . . . . . . 42 12.2. Informative References . . . . . . . . . . . . . . . . . 43 Appendix A. Protocol Interaction Diagrams . . . . . . . . . . . 44 A.1. Global Dual-Certificate Flow (Three-Phase) . . . . . . . 44 A.2. ARKG Key Derivation Layer . . . . . . . . . . . . . . . . 46 A.3. Mode A: Envelope Delivery Flow . . . . . . . . . . . . . 46 A.4. Mode B: Offline DH Derivation Flow . . . . . . . . . . . 47 Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 48 B.1. Client Signature Construction Steps . . . . . . . . . . . 48 B.2. Server Verification Steps . . . . . . . . . . . . . . . . 49 B.3. Relying Party Verification Procedure . . . . . . . . . . 50 B.4. KMC Core Hints . . . . . . . . . . . . . . . . . . . . . 51 B.5. Historical Compatibility Notes . . . . . . . . . . . . . 51 Appendix C. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 51 Appendix D. OID Quick Reference . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction The Automatic Certificate Management Environment (ACME) protocol [RFC8555] provides a standardized mechanism for automated certificate issuance and management. The ACME core resource model defines an *Order* as a request for a single certificate. Each Order contains the identifiers to be authenticated, the authorizations that must be completed, and the final certificate URL. [GMT.0034-2014] specifies an SM2 dual-certificate system that employs a dual-certificate architecture. In this architecture, each entity is assigned both a signature certificate and an encryption certificate. The signature certificate is used for identity authentication and digital signatures, while the encryption certificate is used for data encryption and key establishment. Both certificates are issued to the same entity but serve different security purposes and are subject to different key management policies. Geng, et al. Expires 21 January 2027 [Page 4] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 A notable feature of the SM2 dual-certificate system is that the encryption private key is generated by the Key Management Center (KMC) and securely delivered to the end entity. The KMC encrypts the encryption private key using the entity's *signature public key* via a digital envelope (as defined in [GMT.0010-2023]), and the end entity decrypts it using its signature private key. This key escrow mechanism is mandated by compliance and regulatory requirements for recoverability and auditability. [I-D.geng-acme-sm2dualcert-extension] defines the basic integration of SM2 dual certificates with ACME, introducing the auth-01 challenge and the digital envelope delivery mechanism. [RFC8739] (ACME STAR) defines automatic renewal of short-term certificates, enabling clients to obtain continuously renewed certificates without repeatedly executing the full ACME flow. 1.1. Motivation SM2 dual certificates are currently at a critical stage of large- scale deployment. However, their issuance and lifecycle management still rely largely on manual procedures, whereas many existing PKI deployments have adopted automated certificate management protocols such as ACME. As certificate lifetimes continue to decrease, automated enrollment, issuance, renewal, and deployment become increasingly important for reducing operational overhead and improving deployment efficiency. Supporting SM2 dual certificates in ACME enables automated lifecycle management while leveraging existing ACME infrastructure and operational practices. The base framework [I-D.geng-acme-sm2dualcert-extension] addresses the "first step" of automated issuance for SM2 dual certificates, but two key issues remain to be solved: First, the encryption certificate private key is centrally escrowed by the KMC. If the KMC stores private keys independently for each certificate, it faces scalability bottlenecks in large-scale deployments (millions of certificates)—the storage, backup, and security management of private keys grow linearly with the number of certificates, becoming a serious operational pain point. Second, the security requirements for encryption certificates are higher than those for signature certificates—private key compromise directly threatens the confidentiality of historical data and is difficult to remediate after the fact. Therefore, encryption certificates naturally require higher renewal frequency than signature certificates, necessitating "automated key rotation" beyond "automated issuance." This document defines an ACME STAR extension on top of the base framework, specifically addressing *automated key rotation* for encryption certificates. By introducing an *Asynchronous Remote Key Geng, et al. Expires 21 January 2027 [Page 5] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 Generation (ARKG) seed chain*, the KMC can derive the full lifecycle key sequence for each encryption certificate in a stateless manner, eliminating the private key storage bottleneck in large-scale deployments while providing security properties such as *key insulation* and *auditable recovery*, enabling encryption certificates to use fresh key pairs at each automatic renewal. This document aims to fill this gap, providing a complete ACME- compliant solution for automated, secure management of large-scale SM2 encryption certificates. 1.2. Problem Statement The standard ACME flow faces three key challenges in the SM2 dual- certificate use case: 1. *Generation and delivery of encryption private keys*: Standard ACME requires the client to generate key pairs, whereas SM2 encryption certificates require the KMC to generate and escrow encryption private keys, necessitating a secure delivery mechanism. STAR [RFC8739] addresses the "automatic renewal" procedural aspect but requires *renewal using the same key pair*, which cannot satisfy the security requirement of "fresh key per epoch" for encryption certificates. 2. *Scalability bottleneck of KMC private key storage*: The base framework requires the KMC to store and manage private keys independently for each encryption certificate. In large-scale deployments (millions of certificates), the storage, backup, and security management of private keys grow linearly with the number of certificates, becoming a serious scalability bottleneck. 3. *Complexity of auditable recovery of historical private keys*: SM compliance requirements [GMT.0034-2014] mandate that encryption private keys shall be capable of auditable recovery. If the KMC stores private keys independently for each certificate, the backup, version management, and secure deletion of historical private keys grow linearly with the number of certificates, increasing operational complexity and risk of exposure. 1.3. Solution Overview This document addresses the above three challenges as follows: * For the *signature certificate*, the standard ACME flow is fully reused; the client may choose to use the traditional CSR method or the pk-01 challenge [I-D.geng-acme-public-key] to complete the application. Geng, et al. Expires 21 January 2027 [Page 6] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 * For the *encryption certificate*, this document defines an automated key rotation mechanism based on Asynchronous Remote Key Generation (ARKG) [Frymann2020], enabling the encryption certificate to achieve *automated key rotation* within the STAR framework —deriving a fresh key pair at each renewal without requiring the client to re-execute authorization challenges or change the certificate retrieval method. * The KMC derives all encryption certificate key pairs through a unified ARKG seed chain, achieving *stateless operations* and complete *auditable recovery capability*. This design maintains compatibility with existing ACME clients and servers, introduces no new Order types, and concentrates all SM-specific logic in a small number of extensionfields such as the auth-01 challenge and authKey. 1.4. Scope and Positioning The extension mechanism defined in this document *applies only to dedicated trust systems that comply with SM standards (GM/T series)* , such as SM2 certificate authentication systems and internal SM PKI deployments. This document *does not apply to* public trust TLS certificate systems (such as the Web PKI governed by the CA/Browser Forum). In the international PKI ecosystem, STAR [RFC8739] and ARI [RFC9773] address large-scale deployment operational challenges from two ends of the certificate lifecycle—STAR brings certificate renewal into the automation track through short-validity certificates, and ARI provides a mechanism for CAs to regulate client renewal behavior. Together, they drive the evolution of international certificate management toward full automation. The SM ecosystem has unique constraints: encryption certificate private keys are centrally escrowed by the KMC, and private key compromise directly threatens historical encrypted data—a backward security gap that no post-hoc revocation mechanism can remedy. This document introduces STAR's automated renewal concept into the SM2 dual-certificate system while adding a *key insulation* property for encryption certificates, ensuring that each epoch uses independently derived key pairs and that compromise of any epoch's private keydoes not affect other epochs. Short validity periods serve "future" exposure window management, while key insulation protects "past" encrypted data security; together they constitute complete security protection for SM2 encryption certificates. *Positioning Statement on Key Escrow*: The security model of [RFC8555] assumes that certificate private keys are generated locally by the client and do not leave the client's trust boundary. The mechanism described in this document, whereby encryption private keys Geng, et al. Expires 21 January 2027 [Page 7] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 are centrally generated and escrowed by the KMC, is a *mandatory requirement* imposed by [GMT.0034-2014] and related regulatory frameworks on encryption certificates. This document merely provides ACME protocol-level adaptation to this established regulatory fact and does not constitute a general recommendation for key escrow architectures, nor does it change the principle that signature certificate private keys must be generated by the client and remain within its domain. *Positioning Statement on ACME Profile*: This document defines an *ACME Profile* that adapts the core protocol of [RFC8555] to the specific deployment scenario of SM2 dual- certificate management in the SM ecosystem. This Profile follows the Profile framework conventions defined in [I-D.ietf-acme-profiles]. *Positioning Statement on Key Escrow Security Boundary*: This document overlays a cryptographically auditable layer (see Section 7) on the established regulatory fact of key escrow. Although the KMC holds all encryption private keys, each epoch's private key is derived via the ARKG seed chain and leaves a verifiable cryptographic commitment in the Merkle tree. Even without relying on the CA's online records, relying parties and auditors can independently verify the cryptographic binding between the encryption certificate and the authorizing signature certificate. This document provides the maximum possible security assurance under the constraint of key escrow through the design philosophy of "escrow auditable" rather than "escrow trusted." 1.5. Relationship to Existing Work * *Based on [I-D.geng-acme-sm2dualcert-extension]*: Inherits the SM2 dual-certificate basic integration framework, digital envelope mechanism, auth-01 challenge, and sm2AuthKeyHash extension. The server directly converts authKey (JWK format) to SubjectPublicKeyInfo for delivery to the KMC. * *Aligned with [I-D.bradleylundberg-cfrg-arkg]*: The ARKG algorithm in this specification is a concrete instantiation of that generic framework on the SM2 curve. * *Based on [RFC8739] STAR*: The signature certificate uses the STAR automatic renewal mode; the encryption certificate borrows STAR's "logical resource" modeling approach and three-phaseflow structure. * *References [RFC6962] Certificate Transparency*: The Merkle root for audit proofs is submitted to CT logs. Geng, et al. Expires 21 January 2027 [Page 8] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 * *Follows [I-D.ietf-acme-profiles]*: This document, as an ACME Profile, follows the conventions of that framework. 1.6. Relationship to Delegated Credential Scenarios The encryption certificate key escrow and automated rotation problem addressed by this document can be viewed as a special certificate delegation scenario—the client delegates generation and management of the encryption private key to the KMC while retaining exclusive control of the signature key. This differs from [RFC9115] (Delegated Credentials), which addresses "certificate issuance delegation"; this document addresses "*key generation and escrow delegation*." The differences are as follows: +============+=====================+============================+ | Dimension | RFC 9115 (Delegated | This Document (GM Profile) | | | Credentials) | | +============+=====================+============================+ | Delegated | Certificate | Encryption key generation | | object | issuance authority | and escrow | +------------+---------------------+----------------------------+ | Delegatee | Third party (e.g., | KMC (Key Management | | | CDN) | Center) | +------------+---------------------+----------------------------+ | Private | Delegatee holds | KMC generates and escrows; | | key holder | private key | client holds copy | +------------+---------------------+----------------------------+ | Use case | Third party applies | Compliance requirement for | | | for certificate on | encryption private key to | | | behalf of principal | be managed by KMC | +------------+---------------------+----------------------------+ Table 1 [RFC9115] provides a Profile for the "third party holds private key" scenario; this document provides a Profile for the "third party generates and escrows private key" scenario. Together, they constitute a complete picture of ACME delegation capabilities. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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. This document uses all terms defined in Section 2 of [I-D.geng-acme- sm2dualcert-extension]. Geng, et al. Expires 21 January 2027 [Page 9] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 *New terms defined in this specification*: * *ARKG*: Asynchronous Remote Key Generation, as defined in [Frymann2020]. The ARKG in this specification is a concrete instantiation of the generic framework in [I-D.bradleylundberg-cfrg-arkg] on the SM2 curve. * *KMC Seed*: seed_kmc, a long-term secret held by the KMC, used to derive all encryption certificate key pairs via ARKG. * *Epoch*: The version number of an encryption certificate, incremented at each key rotation. * *Mode A (ARKG Envelope Delivery)*: A mode in which the KMC derives key pairs via ARKG and delivers the private key to the client via a digital envelope.*Mode B (ARKG Offline DH Derivation)*: A mode in which the initial key is obtained via envelope delivery, and subsequent keys are derived offline by the client. * *ARKG Derivation Factor (cred)*: A public parameter used in ARKG for key derivation. * *KMC Public Key Sequence*: pk_kmc[j], a series of public keys derived from seed_kmc, used for offline DH derivation in Mode B. * *account_thumbprint*: The JWK Thumbprint of the ACME account public key that initiated the request, computed as per Section 3 of [RFC7638]. This value provides cryptographic account public key binding in the auth-01 signature input, enabling offline auditability of the signature. *Note*: JWK Thumbprint [RFC7638] uses the SHA-256 hash algorithm, which is a mandatory requirement of RFC 7638. This use of SHA-256 is limited to JWK Thumbprint computation and does not affect the consistency of this document's SM algorithm suite (SM2/SM3/SM4). *Automated Key Rotation*: In this specification, this term refers to the mechanism by which encryption certificates derive fresh key pairs at each automatic renewal, distinguishing it from other terms such as "Key Evolution." This specification is technically implemented based on ARKG and uses "Automated Key Rotation" in business description to more accurately reflect its actual effect in the certificate renewal context. Geng, et al. Expires 21 January 2027 [Page 10] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 3. Unified ARKG Key Derivation System This section defines the core cryptographic infrastructure of this specification—the ARKG key derivation system. *Mode A and Mode B share the complete cryptographic mechanisms defined in this section*; the difference lies only in the private key delivery method defined in Section 4. 3.1. ARKG SM Cryptographic Suite The ARKG SM cryptographic suite adopted by this protocol consists of the following cryptographic algorithms: +==============+============+===============+===================+ | Algorithm | SM | Specification | Purpose | | Component | Algorithm | Reference | | +==============+============+===============+===================+ | Public-key | SM2 | GM/T | Elliptic curve | | cryptosystem | (sm2p256v1 | 0003-2012 | group operations, | | | curve) | | public/private | | | | | key derivation | +--------------+------------+---------------+-------------------+ | Hash | SM3 | GM/T | Seed chain, | | function | (256-bit | 0004-2012 | Merkle tree, | | | output) | | signature hashing | +--------------+------------+---------------+-------------------+ | Pseudorandom | HMAC-SM3 | GM/T | Derivation factor | | function | | 0042-2015 | derivation (PRF) | +--------------+------------+---------------+-------------------+ | Symmetric | SM4 | GM/T | Digital envelope | | encryption | (128-bit | 0002-2012 | encryption (Mode | | | key) | | A) | +--------------+------------+---------------+-------------------+ | Random | RNG | GM/T | Seed generation, | | number | conforming | 0108-2021 | key derivation | | generation | to GM/T | | | | | 0108-2021 | | | +--------------+------------+---------------+-------------------+ Table 2 *Algorithm OID Specification*: The standard OID for the SM3 cryptographic hash algorithm adopted in this document is 1.2.156.10197.1.401, as defined in [GMT.0006-2023]. This OID shall be used for all newly generated certificates and signatures. Refer to Appendix B for handling of legacy alternative OIDs. ARKG consists of the following four polynomial-time algorithms: Geng, et al. Expires 21 January 2027 [Page 11] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 (1) Setup(1^λ) → params: Takes a security parameter as input and outputs system public parameters: * Elliptic curve group G (prime order q, generator P), using the SM2 curve * Hash function H: SM3 * Pseudorandom function PRF: HMAC-SM3 (2) KeyGen(params) → (pk_seed, sk_seed): Generates a seed key pair, sk_seed ← Z_q, pk_seed = sk_seed · P. The seed private key is securely held by the KMC. In this specification, sk_seed corresponds to seed_kmc. Random number generation MUST conform to [GMT.0108-2021] requirements. (3) DerivePK(pk_seed, cred) → pk: pk = pk_seed + (PRF(cred) mod q) · P, where + denotes elliptic curve point addition. (4) DeriveSK(sk_seed, cred) → sk: sk = (sk_seed + PRF(cred)) mod q *Security Note*: The security of cred = PRF(k_i, meta_i) depends on the confidentiality of k_i. Even if an attacker learns the plaintext value of cred, they cannot compute the output of PRF(cred) because the key of PRF is k_i. Therefore, cred can be safely transmitted over public channels (Mode B). 3.2. Seed Chain and Key Derivation The KMC maintains a seed chain: k_0 = random secret (256 bits), generated using an RNG conforming to {{GMT.0108-2021}} k_{i+1} = H(k_i || 0x00 || counter_i) where counter_i is a monotonically increasing integer (starting from 0). counter_i MUST be incremented with each epoch and *MUST NOT* be reused. The derivation factor is defined as: cred_i = PRF(k_i, meta_i), where meta_i contains domain separation information including the domain name, epoch number, and algorithm identifier. *meta_i Encoding Specification*: meta_i MUST use the following ASN.1 DER-encoded SEQUENCE structure: Geng, et al. Expires 21 January 2027 [Page 12] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 MetaData ::= SEQUENCE { domain OCTET STRING, -- UTF-8 encoded domain name epoch INTEGER, -- Current epoch number (64-bit unsigned integer) algorithm OCTET STRING, -- UTF-8 string of algorithm identifier purpose OCTET STRING -- Domain separation string, value "key-derivation" } k_i is used as the HMAC-SM3 key, and DER-encoded(MetaData) is used as the HMAC-SM3 message. The output of PRF(k_i, meta_i) is 256 bits (SM3 output length), used directly as the cred value in DerivePK and DeriveSK. *Domain Separation*: * Seed chain: H(k_i || 0x00 || counter_i) * Merkle tree leaf: H(0x01 || sk_i || meta_i) * Mode B KMC public key: pk_kmc[j] = DerivePK(pk_seed, "kmc-public- key" || 0x00 || uint32_to_bytes(j)) * Mode B DH derivation domain separation: meta_i_dh uses the same MetaData structure as above, but with the purposefield set to "dh- derivation" *Key Derivation*: For each epoch i, the KMC derives: sk_i = DeriveSK(sk_seed, cred_i) pk_i = DerivePK(pk_seed, cred_i) *seed_kmc Generation Requirements*: Generation of seed_kmc *MUST* satisfy the following requirements: 1. Use a cryptographically secure random number generator conforming to [GMT.0108-2021]. 2. *SHOULD* combine multiple independent entropy sources (e.g., hardware RNG, operating system entropy, administrator-provided random seeds). 3. *SHOULD* perform entropy estimation after generation to ensure at least 256 bits of cryptographic strength. 4. For high-security deployments, *RECOMMENDED* to use a multiple- party generation ceremony, with the seed stored in a threshold- shared manner. Geng, et al. Expires 21 January 2027 [Page 13] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 3.3. Security Properties * *Correctness*: pk_i = sk_i · P holds for all epochs. * *Past-key compromise resistance*: Even if the current private key is compromised, historical private keys cannot be recovered as long as the historical derivation factors cred_i are not compromised. * *Future-key compromise resistance*: The one-way property of the seed chain ensures that compromise of a future seed does not affect historical keys. * *Auditability*: The KMC stores the complete (k_i, meta_i) sequence and can recover private keys for any epoch under authorization with verifiable proof. 4. Encryption Private Key Delivery Modes Based on the unified ARKG key derivation system defined in Section 3, this section defines two private key delivery modes. Both modes share the same key derivation infrastructure (seed_kmc → cred_i → (pk_i, sk_i)), differing only in the final delivery mechanism of sk_i. 4.1. Mode A: ARKG Envelope Delivery (Default) Mode A private key deliveryflow: 1. *Key Derivation*: The KMC derives the current epoch key pair (pk_i, sk_i) via the ARKG seed chain (per Section 3). 2. *Envelope Assembly*: The KMC encapsulates sk_i in a digital envelope. The envelope structure follows CMS EnvelopedData or SignedAndEnvelopedData syntax ([RFC5652] /[GMT.0010-2023]), encrypted using the client's signature public key. 3. *Envelope Delivery*: The envelope is returned in the finalize response or via the envelope endpoint. 4. *Client Decryption*: The client decrypts the envelope using its signature private key to obtain sk_i. *CMS Version and Profile*: * When using EnvelopedData, the versionfield MUST be set to 0 (per [RFC5652] Section 6.1). Geng, et al. Expires 21 January 2027 [Page 14] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 * When using SignedAndEnvelopedData, the versionfield MUST be set to 1 (per [RFC5652] Section 10.2, when using KeyTransRecipientInfo). * The digestAlgorithmsfield MUST contain at least one digest algorithm identifier and *MUST* use the SM3 algorithm (OID 1.2.156.10197.1.401). * The keyEncryptionAlgorithm *MUST* use the SM2 public-key encryption algorithm OID 1.2.156.10197.1.301.3, with parameters set to NULL (encoded as 05 00). * The contentEncryptionAlgorithm MUST use the SM4-CBC algorithm OID 1.2.156.10197.1.104.2. * If using SignedAndEnvelopedData, *signature MUST be applied before encryption*. *Note*: SignedAndEnvelopedData is noted as having ill-defined semantics in [RFC5652] (see [RFC5652] Section 10). This document uses this type for compatibility with [GMT.0010-2023]. Implementers should be aware of this semantic limitation; in deployment scenarios where only confidentiality protection is required and the communication channel already provides integrity protection, using EnvelopedData (version = 0) is also an acceptable alternative (see Section 3.3.1 of the base framework [I-D.geng-acme-sm2dualcert- extension]). 4.2. Mode B: ARKG Offline DH Derivation (OPTIONAL Enhancement) Mode B is suitable for scenarios where the client needs *fully offline private key derivation* or pursues *extreme stateless KMC operations*. Mode B's bootstrap phase depends on digital envelope delivery of the initial sk_0; therefore, the client MUST explicitly set includeEnvelope: true when creating the order. Mode B private key deliveryflow: *Step 1: Initial Private Key Acquisition (via Mode A Envelope Delivery)* The client *obtains the initial private key sk_0 via Mode A envelope delivery*. *Critical Dependency*: Mode B's bootstrap phase depends on digital envelope delivery of sk_0; therefore, the client *MUST* explicitly set includeEnvelope: true when creating the order. If the client does not set this, the server will omit envelope assembly, the client will be unable to obtain sk_0, and subsequent key rotation cannot Geng, et al. Expires 21 January 2027 [Page 15] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 commence. In Mode B, the includeEnvelope parameter only affects the initial bootstrap phase envelope delivery. Once switched to Mode B's offline DH derivation, this parameter no longer applies. *Step 2: KMC Public Key Derivation* The KMC derives the KMC public key sequence from the same seed_kmc: sk_kmc[j] = DeriveSK(sk_seed, "kmc-public-key" || 0x00 || uint32_to_bytes(j)) pk_kmc[j] = DerivePK(pk_seed, "kmc-public-key" || 0x00 || uint32_to_bytes(j)) Each pk_kmc[j] has a preset validity period (RECOMMENDED: 1 year). *Security Constraints*: sk_kmc[j] MUST be protected at the same security level as seed_kmc. Operations using sk_kmc[j] MUST be performed in a protected cryptographic environment (e.g., HSM or TEE) to prevent side-channel attacks. Sensitive data in memory MUST be zeroized immediately after operations complete. *Old Key Retention*: Rotated old sk_kmc[j] MUST be retained for at least the *maximum encryption certificate validity period permitted in the current deployment*. If the maximum certificate validity period is less than 30 days, MAY retain for 30 days to provide a securitymargin. This retention period ensures that all encryption certificate private keys derived using that pk_kmc[j] remain auditable and recoverable throughout the certificate validity period. *Step 3: KMC Public Key Distribution* pk_kmc[0] is returned directly in the finalize response via the kmc_public_keyfield. Updates to subsequent pk_kmc[j] (j>0) are obtained via the GET /acme/key-rotation-state/{orderID}/kmc-public- key endpoint (see Section 6.4). *Step 4: Subsequent Private Key Offline Derivation* The client holds the current private key sk_i and the current KMC public key pk_kmc[j], computing entirely offline: *Client Computation*: delta_i = PRF(DH(sk_i, pk_kmc[j]), i || meta_i_dh) sk_{i+1} = sk_i + delta_i *Server Computation*: Geng, et al. Expires 21 January 2027 [Page 16] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 delta_i = PRF(DH(sk_kmc[j], pk_i), i || meta_i_dh) pk_{i+1} = pk_i + delta_i · P sk_{i+1} = sk_i + delta_i Due to the symmetry of DH, both parties compute the same delta_i, ensuring sk_{i+1} · P = pk_{i+1}. *Encoding Specification*: * The output of DH(sk_i, pk_kmc[j]) is an elliptic curve point on the SM2 curve (affine coordinates). This point MUST be encoded in SEC1 uncompressed point format (0x04 || x || y, where x and y are each 32-byte big-endian integers) as input to the PRF. * i is a 64-bit unsigned integer, *MUST* be encoded as 8 bytes in big-endian byte order. * meta_i_dh uses the same ASN.1 DER-encoded MetaData structure as in Section 3.2, but with the purposefield set to "dh-derivation". The complete PRF input is: PRF_input = DH_point_bytes || uint64_to_big_endian(i) || DER_encoded(MetaData_dh) *Client Verification*: After obtaining each new certificate, the client MUST verify that sk_{i+1} · P == pk_{i+1}.*Verification Failure Recovery Procedure*: If verification fails, the client MUST: 1. Check whether the local derivation state (sk_i, pk_kmc[j], epoch) is consistent with the server state. If inconsistent, obtain the latest state via GET /acme/key-rotation-state/{orderID}. 2. If the state is consistent but verification still fails, the client SHOULD retry derivation and verification up to 3 times. 3. If retries still fail, the client MUST terminate rotation and report a keyDerivationFailed error. Recovery options include: *re-initiate the bootstrapflow* (i.e., re-apply for an encryption certificate with includeEnvelope: true to obtain a new initial private key via Mode A), or *fall back to Mode A* (if supported by the server). *Step 5: KMC Public Key Update* The client detects updates to pk_kmc[j] by periodically polling the state resource. Detection is performed by checking the value of the kmcPublicKeyVersion field in the key-rotation- state resource. When this value changes, the client SHOULD obtain the new KMC public key Geng, et al. Expires 21 January 2027 [Page 17] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 via GET /acme/key-rotation-state/{orderID}/kmc-public-key. The recommended polling strategy is determined by the client based on the deployment scenario; the server SHOULD indicate caching policy via the Cache-Control header to help clients optimize polling frequency (see Section 6.4). 4.3. Mode Relationship and Migration *Mode Relationship*: Both modes share the same ARKG key derivation infrastructure. Mode B's initial bootstrap depends on Mode A's envelope mechanism. Mode B is an *enhancement* of Mode A (switching to offline derivation after obtaining the initial private key), not a replacement. *Mode Migration*: Clients can migrate smoothly from Mode A to Mode B: complete one envelope delivery to obtain the current sk_i, obtain pk_kmc[0], and switch to offline derivation for subsequent renewals. *Interoperability*: Servers MUST support Mode A and MAY support Mode B. Clients select the mode via the derivationModefield. 4.4. Encryption Private Key Delivery Mode Selection Guide The following decision guide applies to deployers needing to select an encryption private key delivery mode. All servers MUST support Mode A; Mode B is an OPTIONAL enhancement. Geng, et al. Expires 21 January 2027 [Page 18] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 +============================+=============+========================+ | Deployment Scenario | Recommended | Rationale | | | Mode | | +============================+=============+========================+ | Maximum compatibility with | *Mode A | Full inheritance, | | base framework required | (Envelope)* | zero protocol | | | | deviation | +----------------------------+-------------+------------------------+ | Lowest deployment risk | *Mode A | Mature mechanism, | | desired | (Envelope)* | already validated | +----------------------------+-------------+------------------------+ | Large-scale deployment | *Mode B | Stateless | | (millions of certificates) | (Offline | derivation, client | | | DH)* | offline | +----------------------------+-------------+------------------------+ | Client needs offline | *Mode B | Only online for | | private key derivation | (Offline | certificate | | | DH)* | retrieval | +----------------------------+-------------+------------------------+ | Key insulation security | *Mode B | Private key | | property required | (Offline | compromise does not | | | DH)* | affect other epochs | +----------------------------+-------------+------------------------+ | Most direct audit recovery | *Mode A | Storage is evidence | | requirement | (Envelope)* | | +----------------------------+-------------+------------------------+ | PQC migration preparation | *Mode B | Smoothly | | prioritized | (Offline | replaceable with | | | DH)* | PQC KEM | +----------------------------+-------------+------------------------+ Table 3 Both modes can coexist on the same server, and different orders may use different modes. 5. Protocol Flow This section borrows the three-phase structure of [RFC8739] STAR, dividing the synchronized short-term automatic renewal process for SM2 dual certificates into three phases: *Bootstrap*, *Auto Renewal*, and *Certificate Access*. 5.1. Phase One: Bootstrap *Step 1: Signature Certificate Authorization and Issuance* Geng, et al. Expires 21 January 2027 [Page 19] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 The signature certificate is the foundation of identity authentication and *MUST* complete domain authorization verification and issuancefirst. 1. The client generates a signature key pair, creates a signature certificate order, and MUST include "auto-renewal": true in the newOrder request. 2. The client completes standard ACME authorization challenges (HTTP-01, DNS-01, or pk-01). *The signature certificate MUST NOT use the auth-01 challenge*. 3. Submit finalize; the CSR contains the signature public key. The server issues the signature certificate. *Step 2: Encryption Certificate Initial Issuance (Reusing Authorization)* The encryption certificate MUST be initiated *after the signature certificate is issued*, *reusing* the signature certificate's authorization. The auth-01 challenge in the encryption certificate order MUST be placed in a *dedicated authorization object* (per Section 3.3.2 of the base framework [I-D.geng-acme-sm2dualcert- extension]). This dedicated authorization object MUST NOT contain any othertype of challenge. The server MUST create exactly one auth-01 dedicated authorization object for each encryption certificate Order. *auth-01 Signature Construction* (per Section 3.3.2 of [I-D.geng- acme-sm2dualcert-extension]): message = "ACME auth-01" || 0x00 || challenge_url || 0x00 || token_utf8_bytes || 0x00 || account_thumbprint The signature value MUST use the normalized form s <= n/2. The challenge URL is guaranteed by the server to be globally unique and non-reusable; the token has at least 128 bits of entropy; together they ensure non-replayability of the signature. The account_thumbprint provides account binding, ensuring the signature cannot be transferred to another account. Upon successful challenge, the server triggers the KMC to derive the initial key pair (pk_0, sk_0) via ARKG, assembles the digital envelope, and returns it in the finalize response. Mode B additionally derives and delivers pk_kmc[0]. Geng, et al. Expires 21 January 2027 [Page 20] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 5.2. Phase Two: Auto Renewal * *Signature Certificate Auto Renewal (STAR)*: Automatic renewal per the [RFC8739] STAR mode. * *Encryption Certificate Auto Rotation*: Mode A delivers new private keys via envelope; Mode B derives new private keys via offline DH. * *Dual-Certificate Validity Binding*: The notAfter of the encryption certificate MUST be ≤ the notAfter of the signature certificate. If the signature certificate is revoked or expires, the encryption certificate SHOULD also be revoked or have rotation stopped. * *Synchronized Renewal Mechanism*: Automatic renewal/rotation of both certificate types MUST be synchronized. The server MUST track the bound signature certificate STAR order via the syncWithfield. If the signature certificate order referenced by syncWith is deleted or unreachable, the server SHOULD set the encryption certificate's rotation status to paused and log the event in the audit log. 5.3. Phase Three: Certificate Access The client obtains the currently valid short-term certificate via a *fixed URL*. The encryption certificate URL isfixed in the state resource. 6. ACME Protocol Extensions The extensions defined in this document follow the general ACME extension pattern: extension parameters are passed in the *JWS Payload* of the newOrder request, consistent with the newOrder request format defined in [RFC8555] Section 7.4. All extension parameters are protected by JWS signatures, ensuring their integrity and source authenticity. Standard ACME servers ignore unknown payloadfields, ensuring backward compatibility. 6.1. Directory Object Extensions Geng, et al. Expires 21 January 2027 [Page 21] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 { "key-rotation": { "supportedModes": [ "envelope", "dh-offline" ], "supportedSyncModes": [ 1, 3 ], "supportedAlgorithms": [ "sm2p256v1-sm3" ], "maxEpochDuration": 2592000, "minEpochDuration": 604800 }, "key-rotation-state": "https://.../acme/key-rotation-state/" } * supportedModes: List of encryption private key delivery modes supported by the server. "envelope" is the default mode and MUST be supported by all servers; "dh-offline" is an OPTIONAL enhancement mode. * supportedSyncModes: List of synchronization mode identifiers supported by the server. Mode 1 indicates "standard DH derivation mode"; mode 3 indicates "composite derivation mode" (currently undefined, reserved for future extension). Thefirst byte provided by the client in the seedSyncfield MUST be within this list. * supportedAlgorithms: List of algorithm combinations supported by the server. The string format is curve-hash; currently, "sm2p256v1-sm3" is supported. The client MUST select one item from this list for the algorithmfield in the newOrder request. *Algorithm Extension Strategy*: If the SM Administration releases post-quantum replacement algorithms for SM2 or other algorithm combinations in the future, new algorithm identifiers (such as "sm2p256v1+ml-kem-768" or the standard name assigned by the SM Administration) can be registered in this registry. Clients and servers negotiate via the directory object for smooth migration. This mechanism aligns with the IETF's ongoing "Quantum-Ready Profiles for ACME" and "Post-Quantum Cryptographic Agility Profile for ACME" work. * maxEpochDuration/minEpochDuration: Maximum/minimum epoch duration allowed by the server (in *seconds*). Geng, et al. Expires 21 January 2027 [Page 22] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 * key-rotation-state: Directory template URL for the state resource.### 6.2. Creation of Encryption Certificate Orders 6.2. Creation of Encryption Certificate Orders { "identifiers": [ { "type": "dns", "value": "example.com" } ], "authorizations": [ "https://.../authz/123" ], "authKey": { "kty": "EC", "crv": "sm2p256v1", "x": "...", "y": "..." }, "includeEnvelope": true, "auto-renewal": true, "key-rotation": { "algorithm": "sm2p256v1-sm3", "derivationMode": "dh-offline", "seedSync": "base64url(0x01 || eph_pk)", "initialEpoch": 0, "syncWith": "https://.../order/sig/123" } } *key-rotation Object Field Descriptions*: * algorithm: REQUIRED. Algorithm combination identifier; value MUST be one of the supportedAlgorithms list in the directory object. * derivationMode: OPTIONAL. Encryption private key delivery mode; values are "envelope" (Mode A) or "dh-offline" (Mode B). Default is "envelope". If the server does not support the requested mode, it SHOULD return an unsupportedDerivationMode error. * seedSync: OPTIONAL. Synchronization information for Mode B bootstrap phase. Format is base64url encoding of sync_mode_byte || eph_pk, where thefirst byte sync_mode_byte indicates the synchronization mode (MUST correspond to one of the values in the directory's supportedSyncModes). eph_pk is the public key of a temporary key pair generated by the client, using Geng, et al. Expires 21 January 2027 [Page 23] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 the SM2 curve (sm2p256v1), represented in uncompressed point encoding (0x04 || x || y, 32 bytes each). The temporary private key SHOULD be cleared from memory immediately after initial synchronization completes. This temporary public key is used to establish initial synchronization of the KMC public key index during the bootstrap phase. If the client does not provide thisfield, the server SHOULD use default value 0x01 as the synchronization mode and generate the corresponding temporary public key. * initialEpoch: OPTIONAL. Requested initial epoch number. Default is 0. If the server does not support the specified value (e.g., already exists), it SHOULD return an epochRollback error. * syncWith: OPTIONAL. Bound signature certificate STAR order URL for synchronized dual- certificate renewal. If provided, the server MUST validate its validity. *includeEnvelope Field*: Default is false. The server includes envelope in delivery only when the client explicitly sets it to true. Mode B MUST explicitly set includeEnvelope: true. *Server Processing*: 1. Verify that authKey is present and correctly formatted. If missing, return authKeyMissing. 2. If derivationMode is "dh-offline" but the server does not support it, return unsupportedDerivationMode. 3. Verify that the signature certificate order referenced by syncWith exists, is valid, and contains the same identifier. 4. Verify that the signature certificate authorization object corresponding to that identifier is valid and not expired. 5. *Verify Signature Certificate Existence*: Before triggering the KMC, verify that the signature certificate corresponding to authKey has been issued by this CA to the same ACME account, has identifiers consistent with the current Order, and is in a valid state. If verification fails, return signingCertRequired. 6. Create a key-rotation-state resource with initial status "pending". 7. Trigger the KMC to derive the initial encryption key pair (pk_0, sk_0) via ARKG. Geng, et al. Expires 21 January 2027 [Page 24] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 8. *Envelope Assembly*: If the client explicitly sets includeEnvelope: true, the server MUST assemble and return the digital envelope. Mode B MUST set includeEnvelope: true. 9. If Mode B, additionally derive and deliver pk_kmc[0]. 10. Order enters "ready" state. *Response after successful finalize*: { "status": "valid", "certificate": "https://.../cert/123", "envelope": "base64url(...)", "keyRotationState": "https://.../acme/key-rotation-state/123" } The envelope field in this example is present only when the client explicitly sets includeEnvelope: true. *Fatal Error Definitions*: * invalidCSR, invalidKeyUsage, invalidSM2Signature, signingCertRequired → status transitions to invalid * kmcUnavailable, envelopeGenerationFailed → status remains pending (retryable) *Order and State Resource Relationship*: The order enters the valid terminal state and does not change thereafter (per [RFC8555]). The key rotation lifecycle is managed by the independent key-rotation-state resource. 6.3. Key Rotation State Resource and State Transitions The state machine of this resource maintains semantic consistency with STAR's ([RFC8739]) auto-renewal state machine—the canceled state cancels the rotation process, not the already-issued certificate. *State Resource*: Geng, et al. Expires 21 January 2027 [Page 25] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 { "status": "active", "order": "https://.../order/123", "epoch": 0, "expires": "2026-07-23T00:00:00Z", "nextEpoch": "2026-07-23T00:00:00Z", "certificate": "https://.../cert/123", "derivationMode": "dh-offline", "envelope": "https://.../acme/key-rotation-state/123/envelope", "kmcPublicKey": "https://.../acme/key-rotation-state/123/kmc-public-key", "kmcPublicKeyVersion": 0, "boundSigningCert": "https://.../cert/sig/123", "syncWith": "https://.../order/sig/123" } *Polling Optimization*: Servers SHOULD support ETag or Last-Modified headers on the key-rotation-state resource, allowing clients to use conditional requests (If-None-Match/If-Modified-Since) to reduce unnecessary transfers. This optimization is consistent with the general design for resource access in [RFC8555]. *State Transitions*: Geng, et al. Expires 21 January 2027 [Page 26] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 +===============+=====================+========================+ | Current State | Allowed Transitions | Trigger Condition | +===============+=====================+========================+ | pending | → active | finalize successful | +---------------+---------------------+------------------------+ | pending | → invalid | finalize fatal failure | | | | or expires timeout | +---------------+---------------------+------------------------+ | pending | → canceled | POST /cancel or | | | | syncWith cancellation | +---------------+---------------------+------------------------+ | active | → paused | POST /pause or | | | | syncWith binding失效 | +---------------+---------------------+------------------------+ | active | → canceled | POST /cancel or | | | | syncWith cancellation | +---------------+---------------------+------------------------+ | paused | → active | POST /resume | +---------------+---------------------+------------------------+ | paused | → canceled | POST /cancel or | | | | syncWith cancellation | +---------------+---------------------+------------------------+ | invalid/ | → none | Terminal states | | canceled | | | +---------------+---------------------+------------------------+ Table 4 *syncWith Binding Failure Handling*: When the signature certificate order referenced by syncWith is deleted or unreachable, the server SHOULD set the encryption certificate's rotation status to paused and log the event in the audit log. The client may attempt recovery via POST /resume (see Section 6.5). 6.4. Certificate and Private Key Retrieval * *Envelope Retrieval (Mode A)*: GET /acme/key-rotation- state/{orderID}/envelope, MUST set Cache-Control: no-store, private. * *Envelope Re-retrieval Mechanism*: If the server uses asynchronous issuance, the envelope is delivered via POST-as-GET after the Order transitions to valid. The server MUST support re-retrieval throughout the Order's retrievable lifecycle. * *KMC Public Key Retrieval (Mode B)*: GET /acme/key-rotation- state/{orderID}/kmc-public-key. Geng, et al. Expires 21 January 2027 [Page 27] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 * *KMC Public Key Update Detection*: Clients detect updates to pk_kmc[j] by periodically polling the key-rotation-state resource, checking for changes in the kmcPublicKeyVersionfield value. When this value changes, the client SHOULD obtain the new KMC public key via GET /acme/key-rotation-state/{orderID}/kmc-public-key. The recommended polling interval for clients is half of the max- age or expires time indicated by the state resource; if the server does not provide caching hints, the client SHOULD use a polling interval not exceeding 24 hours. 6.5. Key Rotation Management * *Automatic Advancement*: The server automatically advances epoch at nextEpoch. * *Manual Management Endpoints*: /pause, /resume, /advance, /cancel. * *POST /resume Request Format*: Resume paused key rotation. The request body is a JSON object that may include the syncWithfield to re-establish binding with the signature certificate. { "syncWith": "https://.../order/sig/123" } If the syncWithfield is omitted, the server SHOULD attempt to restore the original binding relationship (if still valid). If the server cannot restore the binding, it SHOULD return a syncTargetInvalid error and keep the state resource paused. *Idempotency*: All manual management endpoints are idempotent. For repeated requests that are already in the target state, the server SHOULD return HTTP 200 OK with the current resource state and no side effects. 6.6. Error Handling *Base Framework Error Types*: Geng, et al. Expires 21 January 2027 [Page 28] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 +===================================================+======+=====================+ |Error Type |HTTP |Description | | |Status| | +===================================================+======+=====================+ |urn:ietf:params:acme:error:authKeyMissing |400 |authKey missing from | | | |JWS Payload | +---------------------------------------------------+------+---------------------+ |urn:ietf:params:acme:error:kmcUnavailable |503 |KMC temporarily | | | |unavailable | +---------------------------------------------------+------+---------------------+ |urn:ietf:params:acme:error:envelopeGenerationFailed|500 |Envelope generation | | | |failed | +---------------------------------------------------+------+---------------------+ |urn:ietf:params:acme:error:invalidKeyUsage |400 |KeyUsage does not | | | |meet requirements | +---------------------------------------------------+------+---------------------+ |urn:ietf:params:acme:error:invalidCSR |400 |Encryption | | | |certificate Order | | | |finalize request | | | |contains CSR | +---------------------------------------------------+------+---------------------+ |urn:ietf:params:acme:error:invalidSM2Signature |400 |SM2 signature | | | |verification failed. | | | |Semantically distinct| | | |from | | | |badSignatureAlgorithm| | | |(for unsupported JWS | | | |signature algorithms)| | | |in [RFC8555] | | | |Section 6.7 | +---------------------------------------------------+------+---------------------+ |urn:ietf:params:acme:error:signingCertRequired |403 |No valid signature | | | |certificate found | | | |corresponding to | | | |authKey | +---------------------------------------------------+------+---------------------+ Table 5 *New Error Types Defined in This Specification* Geng, et al. Expires 21 January 2027 [Page 29] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 +===========================+========+==============================+ | Error Type | HTTP | Description | | | Status | | +===========================+========+==============================+ | unsupportedDerivationMode | 400 | Server does not support | | | | requested derivationMode | +---------------------------+--------+------------------------------+ | unsupportedSyncMode | 400 | seedSync mode not | | | | supported | +---------------------------+--------+------------------------------+ | algorithmUnsupported | 400 | Algorithm not supported | +---------------------------+--------+------------------------------+ | authorizationExpired | 400 | Reused signature | | | | certificate authorization | | | | has expired | +---------------------------+--------+------------------------------+ | syncTargetInvalid | 400 | Signature certificate | | | | order referenced by | | | | syncWith is invalid | +---------------------------+--------+------------------------------+ | syncTargetCanceled | 400 | Signature certificate | | | | order referenced by | | | | syncWith has been canceled | +---------------------------+--------+------------------------------+ | epochRollback | 400 | Epoch rollback attempted | +---------------------------+--------+------------------------------+ | epochOutOfRange | 400 | Epoch out of range | +---------------------------+--------+------------------------------+ | envelopeConsumed | 409 | Envelope has already been | | | | consumed | +---------------------------+--------+------------------------------+ | rotationCanceled | 403 | Rotation has been | | | | terminated | +---------------------------+--------+------------------------------+ | endpointNotAvailable | 404 | Endpoint not available in | | | | current mode | +---------------------------+--------+------------------------------+ | keyDerivationFailed | 500 | Private key derivation | | | | verification failed | +---------------------------+--------+------------------------------+ | stateInvalid | 409 | State resource is in a | | | | terminal state | +---------------------------+--------+------------------------------+ Table 6 Geng, et al. Expires 21 January 2027 [Page 30] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 7. Auditable Recovery and Proof The KMC's ability to recover historical private keys via the ARKG seed chain is a core compliance feature of this specification. 7.1. Authorized Audit Procedure * *Mode A*: The KMC provides sk_t directly from storage (or recomputes from the seed). * *Mode B*: The KMC recomputes sk_t from seed_kmc: 1. Recompute cred_t and sk_t = DeriveSK(sk_seed, cred_t) from seed_kmc. 2. Generate proof π_t (see Section 7.2). *Impact of Seed Rotation on Audit*: After rotation, old seeds MUST be retained for at least the maximum certificate validity period (RECOMMENDED: at least 30 days). *Compliance Note*: The KMC's ability to recover private keys via seed derivation is, at the audit compliance level, equivalent to the "private key escrow" capability required by [GMT.0034-2014]. 7.2. Post-hoc Audit Proof Based on Certificate Transparency Logs *Merkle Tree Construction*: Immediately after deriving the private key for each epoch, the KMC computes its hash H(0x01 || sk_i || meta_i) and adds it to the Merkle tree, then MUST securely destroy the private key. For Mode A, the KMC already stores private keys, so Merkle tree construction is OPTIONAL; however, unified execution is recommended to simplify the audit mechanism. *Relationship between Merkle Tree and Seed Chain*: The root of the Merkle tree can be viewed as a public commitment of the KMC seed chain. Auditors can confirm the mathematical consistency between the recovered private key and the certificate public key by verifying the Merkle path, without needing access to the KMC's seed. 8. Security Considerations This document inherits all security considerations from Section 6 of [I-D.geng-acme-sm2dualcert-extension]. This section supplements security requirements specific to this specification. Geng, et al. Expires 21 January 2027 [Page 31] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 8.1. Key Management Security *KMC Seed Compromise Risk*: The security of both modes depends on the confidentiality of seed_kmc. seed_kmc MUST be stored in an HSM (FIPS 140-2 Level 3 or EAL 4+). RECOMMENDED to use a threshold KMC architecture. The consequences of seed_kmc compromise depend on the timing of the compromise: private keys for certificates issued before the compromise can still be derived, but shortening certificate validity periods (7-30 days as recommended by this specification) can narrow the affected time window. Deployers are advised to comprehensively assess risks in conjunction with certificate validity periods and security monitoring strategies. *sk_kmc[j] Security*: sk_kmc[j] MUST be protected at the same security level as seed_kmc. Consequence differences: compromise of seed_kmc allows derivation of all epoch private keys; compromise of sk_kmc[j] only allows derivation of future private keys starting from epoch j.*Seed Rotation and Audit Trail*: Rotated old sk_kmc[j] MUST be retained for at least the maximum certificate validity period (RECOMMENDED: at least 30 days). New seeds are only used for future epoch key derivation. Rotation SHOULD update the KMC's HSM configuration and record the rotation event in the audit log (including timestamp, old seed identifier, new seed identifier). 8.2. Protocol and Communication Security * *Envelope Endpoint Security*: The envelope endpoint MUST require account authentication and MUST set the Cache-Control: no-store, private header. * *KMC and ACME Server Trust Boundary*: Communication security follows the requirements of Section 6 of the base framework. The ACME server MUST NOT directly access the KMC's seed private key. * *account_thumbprint Caching Security*: Clients SHOULD recompute account_thumbprint each time it is needed. If caching is desired, cache entries MUST be invalidated immediately upon account key change, and cache TTL SHOULD NOT exceed 24 hours. 8.3. Cryptographic Security *DH Public Key Validity Verification*: Before performing DH computation, both server and client MUST verify the validity of the peer's public key—the public key point MUST NOT be the point at infinity, MUST satisfy the SM2 curve equation, and MUST be in the correct subgroup (q · P == O). Unverified public keys may lead to small-subgroup attacks. Verification algorithms SHOULD use constant- time implementation to prevent attackers from obtaining sensitive Geng, et al. Expires 21 January 2027 [Page 32] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 information through timing analysis. *auth-01 Signature Security*: The account_thumbprint in the auth-01 signature input provides cryptographic account binding, enabling offline auditability of the signature without relying on the CA's online records. The signature value MUST use the normalized form s <= n/2 to prevent signature malleability attacks. 8.4. Compliance and Coordination *Encryption Certificate MUST Include sm2AuthKeyHash Extension*: Per Section 3.4 of the base framework [draft-geng-acme-sm2dualcert- extension], encryption certificates issued under this specification MUST include this extension. This extension is non-critical (critical = FALSE). Relying parties that do not understand this extension can still accept the certificate. Relying parties that need to verify the dual-certificate binding relationship SHOULD actively check the existence and hash consistency of this extension. If the extension exists and the hash does not match, they MUST reject trust; if the extension does not exist, they MAY accept the certificate but cannot verify the binding relationship.*syncWith Coordination Strategy*: When the referenced signature certificate order enters the canceled or invalid state, the server SHOULD transition the associated state resource to canceled. When the signature certificate order is deleted or unreachable, the server SHOULD set it to paused (see Section 6.3). *Simplification of Revocation Strategy through Key Rotation*: The key rotation mechanism in this specification simplifies revocation decisions for encryption certificates. Because each epoch's certificate has an independent key pair and short validity period, stopping automatic rotation can equivalently replace revocation operations without triggering immediate CRL/ OCSP updates, thereby reducing the load pressure on revocation infrastructure in large- scale scenarios. 8.5. Post-Quantum Cryptography Preparedness This protocol is currently based on the SM2 elliptic curve cryptosystem, which is based on the Elliptic Curve Discrete Logarithm Problem (ECDLP) and faces quantum computing threats. Although large- scale universal quantum computers have not yet become a reality, early consideration of post-quantum cryptography (PQC) migration paths is critical for the long-term security of certificate systems. *Threat Model*: Geng, et al. Expires 21 January 2027 [Page 33] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 * The effective security strength of the SM2 algorithm family in a quantum computing environment is approximately half of its classical strength (Grover's algorithm provides square-root acceleration for symmetric ciphers), while Shor's algorithm can solve ECDLP in polynomial time on a quantum computer. Therefore, at the current 128-bit security strength, SM2's quantum effective strength is approximately 64 bits. * Attackers may adopt a "Store Now, Decrypt Later" strategy, where sensitive data encrypted today could be decrypted in the future when quantum computers become available. *Mitigation and Migration Preparation in This Protocol*: * This protocol has already reserved algorithm negotiation mechanisms through the supportedAlgorithmsfield in the directory object (Section 6.1). When the SM Administration releases post- quantum replacement algorithms for SM2 in the future, smooth migration can be achieved by adding new algorithm identifiers to supportedAlgorithms without modifying the protocol framework. * The ARKG seed chain mechanism of this protocol is naturally suitable for combination with composite encryption schemes (see Section 10.1)—the same seed chain can derive both traditional and post-quantum keys simultaneously. This scheme can synergize with the IETF's ongoing composite encryption and composite signature work (LAMPS Working Group). *Deployment Recommendations*: * For deployment scenarios requiring long-term confidentiality (e.g., certificate validity periods exceeding 10 years), deployers are advised to *formulate a PQC migration plan as soon as possible* and monitor the progress of PQC algorithm standards released by the SM Administration.- When building new systems, it is recommended to prioritize deployment methods that support algorithm negotiation (i.e., this protocol's directory object includes the supportedAlgorithmsfield) to enable seamless future switching to PQC algorithms. * Deployers using this protocol's encryption certificates should periodically assess the progress of quantum computing threats and adjust certificate validity periods and security parameters as needed. Geng, et al. Expires 21 January 2027 [Page 34] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 9. Design Considerations This section is non-normative and aims to clarify the key architectural choices made in this document under the hard constraints of the SM2 dual-certificate system and their rationale. 9.1. Independent Key Rotation vs. Synchronization with Signature Certificate *Question*: Should encryption certificate key updates be synchronized with the signature certificate? Why not use the same key rotation cadence for both certificates? *Consideration*: In the SM2 dual-certificate system, the signature certificate is the identity anchor; the consequence of its private key compromise is identity impersonation, which has broad impact but can be controlled through revocation mechanisms. Encryption certificate private key compromise directly threatens the confidentiality of historical data and is difficult to remediate after the fact. *Therefore, encryption certificates naturally require higher update frequency than signature certificates.* *Decision*: This specification decouples the encryption certificate update cycle from the signature certificate, allowing the two certificate types to rotate independently according to their respective security requirements. Encryption certificates can independently adopt shorter validity periods (e.g., 7-30 days) to minimize the exposure window of private key compromise, while signature certificates can maintain longer lifecycles (e.g., 1-2 years). This is a complete implementation of the design philosophy of the SM2 dual-certificate system. 9.2. Two Independent Orders vs. Single Bundle Order *Question*: Since SM2 dual certificates belong to the same entity, should a single Order be used to request both certificates simultaneously? *Consideration*: Within the ACME protocol framework, two main design paths exist: * *Single Order Model*: Requesting both certificates in a single request appears to reduce HTTP round trips but is inconsistent with the Order single-certificate semantics of [RFC8555], leading to complex error handling and state management logic. Geng, et al. Expires 21 January 2027 [Page 35] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 * *Two-Order Model (Selected)*: Creates independent Orders for each certificate, strictly ollowing the resource model of [RFC8555], maintaining maximum compatibility, clear error isolation, and long-term maintainability. *Decision*: This specification chooses the two-Order model. The two certificates establish a binding relationship through the syncWithfield, achieving dual-certificate coordination while maintaining Order atomicity. 9.3. Key Rotation State Resource vs. Order Extension Fields *Question*: Should key rotation status be managed directly as extensionfields of the Order? *Consideration*: In [RFC8555], an Order enters the valid terminal state and does not change thereafter. STAR ([RFC8739]) respects this principle—the Order itself does not reflect subsequent renewal status. * *Order Extension Field Approach*: Placing rotation status in the Order would break Order terminal state semantics. * *Independent State Resource Approach (Selected)*: Placing rotation status in an independent resource keeps the Order terminal state unchanged while providingfine-grained control over the key rotation process (pause, resume, cancel). *Decision*: This specification chooses the independent state resource, respecting the Order terminal state semantics of [RFC8555] while providingfine-grained control over the key rotation process. 9.4. Envelope Delivery vs. Offline DH Derivation *Question*: Do encryption private key delivery methods need both modes? Is envelope delivery alone sufficient? *Consideration*: * *Envelope Delivery (Mode A)*: Fully inherits the envelope mechanism of the base framework, with optimal compatibility, suitable for scenarios requiring consistency with traditional SM deployments. Geng, et al. Expires 21 January 2027 [Page 36] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 * *Offline DH Derivation (Mode B)*: After obtaining the initial private key, subsequent private keys are derived entirely offline without online envelope retrieval, providing key insulation and offline recovery capabilities, suitable for large-scale deployments and client offline scenarios. *Decision*: This specification provides two modes for deployers to choose from. Mode A is the default, ensuring maximum compatibility with the base framework; Mode B is an OPTIONAL enhancement, providingflexibility for deployments pursuing stateless derivation and key insulation. 9.5. Seed Chain Derivation vs. Direct Private Key Storage *Question*: Why introduce the ARKG seed chain? Why not simply have the KMC generate and store key pairs directly? *Consideration*: If the KMC stores private keys for each encryption certificate, storage grows linearly with the number of certificates. In large-scale deployments (millions of certificates), the storage, backup, and security management of private keys become a serious scalability bottleneck. *Decision*: The ARKG seed chain allows the KMC to hold just one seed and derive key pairs for any epoch on demand, eliminating the need to store private keys for each certificate—the KMC transforms from a "key warehouse" to a "key factory," achieving lightweight, scalable stateless operations. At the same time, any historical private key can be auditably recovered through the seed chain, meeting the compliance requirements of [GMT.0034-2014]. *Quantitative Operational Cost Consideration*: In a million- certificate deployment scenario, the direct private key storage mode requires the KMC to maintain N private key records, with storage, backup, and security management overhead growing linearly with N. The seed chain derivation mode reduces storage complexity from *O(N) to O(1)*—the KMC only needs to hold one seed to derive any number of key pairs. At the same time, the complexity for auditors to recover historical private keys is reduced from *O(N) (searching in storage) to O(log N) (via Merkle tree path verification)* , significantly reducing the operational cost of compliance audits. 9.6. Cancellation Semantics Alignment with STAR vs. Custom *Question*: Should the cancellation semantics of the key rotation state align with STAR's cancellation semantics? Geng, et al. Expires 21 January 2027 [Page 37] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 *Consideration*: STAR's ([RFC8739]) cancellation semantics are "cancel the automatic renewal process, but do not revoke already- issued certificates." If this specification adopted different cancellation semantics, it would increase the learning cost and implementation complexity for client developers. *Decision*: The state cancellation semantics of this specification are fully aligned with STAR—the canceled state means the key rotation process has been terminated, but the currently valid encryption certificate remains valid until expiration. The cancellation applies to the automatic rotation process, not the revocation of already- issued certificates. 9.7. Key Insulation as an Additional Security Property for Encryption Certificates *Question*: As noted in Section 1.5, STAR effectively limits the exposure window after private key compromise through short-validity certificates. Is an additional security property needed for encryption certificates? *Consideration*: Encryption certificates protect not only current communications but also historical encrypted data. Even if the exposure window is shortened to days, once a private key is compromised, all historical data encrypted with that key is at risk. *Decision*: This specification borrows STAR's automated renewal concept while adding a *key insulation* property for encryption certificates—each epoch uses independently derived key pairs, and compromise of any epoch's private key does not affect other epochs. Short validity periods protect the "future" exposure window, while key insulation protects "past" encrypted data; together they constitute complete security protection for encryption certificates. 10. Future Considerations 10.1. PQC Migration and Algorithm Extension Mode B's DH mechanism can be replaced with a PQC KEM for smooth migration. The ARKG seed chain mechanism is naturally suitable for combination with composite encryption schemes—the same seed chain can derive both traditional and post-quantum keys simultaneously. The supportedAlgorithms algorithm negotiation mechanism of this specification can coordinate with the IETF's ongoing "Quantum-Ready Profiles for ACME" and "Post-Quantum Cryptographic Agility Profile for ACME" work. In the future, PQC algorithm identifiers can be registered under these frameworks to achieve interoperability with Geng, et al. Expires 21 January 2027 [Page 38] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 the general ACME PQC ecosystem. The composite encryption schemes and composite ML-DSA for CMS/X.509 work being defined by the LAMPS Working Group have potential synergy with this specification's ARKG seed chain mechanism—the same seed chain can derive both traditional keys and composite signature keys simultaneously. 10.2. KMC Performance Planning for Large-Scale Deployments In deployment scenarios with millions of certificates and weekly per- certificate rotation, the KMC's ARKG derivation compute capacity may become a new operational bottleneck. Each epoch's key derivation involves elliptic curve point multiplication (DerivePK) and scalar operations (DeriveSK), which may generate significant CPU load during peak rotation periods. The following performance optimization measures may be standardized in the future: * *Pre-computation*: The KMC can derive (pk_i, sk_i) for multiple future epochs in advance, pre-computing and caching during off- peak periods to mitigate peak load. * *Batch Derivation*: Batch derivation operations for a large number of certificates in the same epoch, utilizing SIMD or GPU acceleration. * *Asynchronous Derivation*: The KMC derives key pairs asynchronously after receiving the finalize request, delivering through the state resource endpoint to avoid blocking the ACME mainflow. Specific optimization strategies depend on deployment scale, hardware capabilities, and security policies, and are not defined within the scope of this specification. However, deployers are advised to assess KMC derivation capacity requirements in advance and develop capacity plans. 10.3. KMC Public Key Rotation Mechanism A standardized rotation protocol for pk_kmc[j] may be defined in the future. Geng, et al. Expires 21 January 2027 [Page 39] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 10.4. Integration with ARI As noted in Section 1.5, ARI plays the role of regulating client renewal behavior in the international PKI ecosystem. The nextEpoch mechanism of this specification is semantically similar to the renewal suggestion information provided by [RFC9773] (ACME Renewal Information, ARI)—both are scheduling indications provided by the server to the client. Future integration or alignment with this specification's key rotation mechanism may be considered to provide clients with unified renewal time recommendations, enabling clients to obtain both certificate renewal and key rotation scheduling information through a single mechanism. 11. IANA and SM Ecosystem Deployment Considerations 11.1. OID Allocation Recommendations +======================+=====================+=====================+ | Extension Name | Recommended OID | Remarks | +======================+=====================+=====================+ | id-sm2-auth-key-hash | 1.2.156.10197.6.3.1 | Currently under | | | | consultation and | | | | confirmation with | | | | the CCSTC, expected | | | | to be allocated | | | | during the | | | | standardization | | | | phase | +----------------------+---------------------+---------------------+ Table 7 * *Temporary OID*: (for experimental deployment only, NOT for production use):id-sm2-auth-key-hash: 1.3.6.1.4.1.2011.2.467.1.3 11.2. ACME Registry Entries ### Geng, et al. Expires 21 January 2027 [Page 40] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 +=========+===========+=====================+======================+ |Registry | Field | Type | Description | | | Name | | | +=========+===========+=====================+======================+ |ACME | key- | object | Contains | |Directory| rotation | | supportedModes, | |Object | | | supportedSyncModes, | |Fields | | | supportedAlgorithms, | | | | | maxEpochDuration, | | | | | minEpochDuration | +---------+-----------+---------------------+----------------------+ |ACME | key- | string | Directory template | |Directory| rotation- | | URL for state | |Object | state | | resource | |Fields | | | | +---------+-----------+---------------------+----------------------+ |ACME | key- | object | Contains algorithm, | |Order | rotation | | derivationMode, | |Object | | | seedSync, | |Fields | | | initialEpoch, | | | | | syncWith | +---------+-----------+---------------------+----------------------+ |ACME | key- | /acme/key-rotation- | Key rotation state | |Resource | rotation- | state/{id} | resource | |Types | state | | | +---------+-----------+---------------------+----------------------+ |ACME | key- | /acme/key-rotation- | Envelope endpoint | |Resource | rotation- | state/{id}/envelope | (Mode A) | |Types | envelope | | | +---------+-----------+---------------------+----------------------+ |ACME | key- | /acme/key-rotation- | KMC public key | |Resource | rotation- | state/{id}/kmc- | endpoint (Mode B) | |Types | kmc- | public-key | | | | public- | | | | | key | | | +---------+-----------+---------------------+----------------------+ Table 8 *Note*: authKey and includeEnvelope are already registered in the base framework [I-D.geng-acme-sm2dualcert-extension]; auto-renewal is already registered in [RFC8739]. 11.3. Algorithm Identifier Registration Establish an algorithm identifier registration mechanism in the SM ecosystem. Initial registration items: Geng, et al. Expires 21 January 2027 [Page 41] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 +=============+=========+=========+===================+===========+ |Identifier |Curve |Hash |Corresponding OID |Purpose | | | |Algorithm| | | +=============+=========+=========+===================+===========+ |sm2p256v1-sm3|sm2p256v1|SM3 |1.2.156.10197.1.301|Currently | | | | |/ |only | | | | |1.2.156.10197.1.401|supported | | | | | |combination| +-------------+---------+---------+-------------------+-----------+ Table 9 12. References 12.1. Normative References [GMT.0034-2014] State Cryptography Administration, "Certificate Authentication System Based on SM2 Cryptographic Algorithm", GM/T 0034-2014 , 2014. [GMT.0010-2023] State Cryptography Administration, "SM2 Cryptographic Algorithm Encrypted Signature Message Syntax Specification", GM/T 0010-2023 , 2023. [GMT.0108-2021] State Cryptography Administration, "Decoy-state BB84 quantum key distribution product technology specification", GM/T 0108-2021 , 2021. [GMT.0006-2023] State Cryptography Administration, "Cryptographic Application Identifier Specification", GM/T 0006-2023 , 2023. [GMT.0078-2020] State Cryptography Administration, "The design guidelines for cryptographic random number generation module", GM/T 0078-2020 , 2020. [GMT.0003.4-2012] State Cryptography Administration, "SM2 Elliptic Curve Public Key Cryptography Algorithm Part 4: Public Key Encryption Algorithm", GM/T 0003.4-2012 , 2012. Geng, et al. Expires 21 January 2027 [Page 42] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 [GMT.0005-2021] State Cryptography Administration, "Randomness test specification", GM/T 0005-2021 , 2021. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor Perales, A., and T. Fossati, "Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)", RFC 8739, DOI 10.17487/RFC8739, March 2020, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC9115] Sheffer, Y., López, D., Pastor Perales, A., and T. Fossati, "An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates", RFC 9115, DOI 10.17487/RFC9115, September 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC9773] Gable, A., "ACME Renewal Information (ARI) Extension", RFC 9773, DOI 10.17487/RFC9773, June 2025, . 12.2. Informative References Geng, et al. Expires 21 January 2027 [Page 43] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 [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-07, 14 June 2026, . [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, . [I-D.bradleylundberg-cfrg-arkg] Lundberg, E. and J. Bradley, "The Asynchronous Remote Key Generation (ARKG) algorithm", Work in Progress, Internet- Draft, draft-bradleylundberg-cfrg-arkg-11, 5 July 2026, . [Frymann2020] Frymann, N., Gardham, D., Kiefer, F., Lundberg, E., Manulis, M., and D. Nilsson, "Asynchronous Remote Key Generation: An Analysis of Yubico's Proposal for W3C WebAuthn", November 2020. Appendix A. Protocol Interaction Diagrams A.1. Global Dual-Certificate Flow (Three-Phase) Client ACME Server KMC | | | Note over Client,K: ═══ Phase One: Bootstrap ═══ Note over Client,ACME Server: ─── Signature Certificate Authorization and Issuance ─── | | | | 1. newOrder for signature cert, auto-renewal: true | |--------------------------------------------->| | | | | | 2. Return Order + authorization challenges | | |<---------------------------------------------| | | | | | 3. Complete all authorization challenges | | |--------------------------------------------->| | | | | Geng, et al. Expires 21 January 2027 [Page 44] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 | 4. finalize (CSR carrying signature public key) | |--------------------------------------------->| | | | | | 5. Server issues signature certificate | | |<---------------------------------------------| | Note over Client,ACME Server: ─── Encryption Certificate Initial Issuance ─── | | | | 6. newOrder for encryption cert, includeEnvelope: true | |--------------------------------------------->| | | | | | 7. Return Order + dedicated auth-01 auth obj | | |<---------------------------------------------| | | | | | 8. Complete auth-01 challenge with quadruple signature | |--------------------------------------------->| | Note over ACME Server: 9. Signature check passed + bound signature cert validation | |--------------------------------------->| | | 10. Trigger KMC subsystem | | | | Note over KMC: 11. ARKG derives new key pair (pk₀, sk₀) | |<----------------------------------------| | | 12. Return encryption cert + digital envelope | | | | | 13. finalize request | | |--------------------------------------------->| | | | | | 14. Respond with cert URL + wrapped envelope | | |<---------------------------------------------| | Note over Client,K: ═══ Phase Two: Auto Renewal ═══ Note over ACME Server: Signature certificate STAR auto-renew logic Note over KMC: Encryption certificate ARKG automatic key rotation Note over ACME Server,KMC: Synchronized trigger via syncWith binding mechanism Note over Client,K: ═══ Phase Three: Certificate Access ═══ | | | | 15. GET fixed certificate URL via POST-as-GET | | |--------------------------------------------->| | | | | | 16. Return currently valid encryption certificate | |<---------------------------------------------| | Note over Client: Geng, et al. Expires 21 January 2027 [Page 45] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 Mode A: Fetch private key via envelope endpoint Note over Client: Mode B: Derive private key offline locally Figure 1: Global Dual-Certificate Flow (Three-Phase) A.2. ARKG Key Derivation Layer +---------------------------+ | KMC Subsystem | +-------------------------------------------------------+ | | | +------------+ +----------------------+ | | | SEED: | | ARKG Derivation Alg | | | | seed_kmc |---->| | | | +------------+ +-----------+----------+ | | | | | +---------------+----------------+ | | | | | | v v | | +------------------+ +----------------+ | | CRED: cred_i | | PKM: KMC pubkey| | | Derivation Factor| | pk_kmc_j | | +--------+---------+ +----------------+ | | | | v | | +--------------------+ | | | PKI: Epoch key pair | | | | pk_i, sk_i | | | +--------------------+ | | | +------------------------------------------------------+ Figure 2: ARKG Key Derivation Layer A.3. Mode A: Envelope Delivery Flow Geng, et al. Expires 21 January 2027 [Page 46] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 +-----------------------------+ +-----------------------------+ | KMC Subsystem | | Client Side | +-----------------------------+ +-----------------------------+ | | | | | +----------------------+ | | +----------------------+ | | | PKI: Epoch Key Pair | | | | DEC: Decrypt envelope | | | | pk_i, sk_i | | | | to retrieve sk_i | | | +----------+-----------+ | | +-----------+----------+ | | | | | | | | v | | v | | +----------------------+ | | +----------------------+ | | | ENV: Assemble envelope| | | | VAL: Verify sk_i matches| | | | via SM4 + SM2 |<--+--------->| cert public key | | | +----------+-----------+ | | +----------------------+ | | | | | | | v | | | | +----------------------+ | | | | | CERT: Issue encryption| | | | | | certificate | | | | | +----------------------+ | | | | | | | +-----------------------------+ +-----------------------------+ Flow logic: 1. KMC generates epoch key pair (pk_i, sk_i) 2. KMC assembles signedAndEnvelopedData envelope using SM4/SM2 3. KMC outputs encryption certificate 4. Envelope payload is delivered to client 5. Client decrypts envelope to get sk_i 6. Client validates sk_i corresponds to certificate public key Figure 3: Mode A: Envelope Delivery Flow A.4. Mode B: Offline DH Derivation Flow Geng, et al. Expires 21 January 2027 [Page 47] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 +------------------------+ +------------------------------------------+ +---------------------------+ | INIT Block | | KMC Subsystem | | Client Side | +------------------------+ +------------------------------------------+ +---------------------------+ | | | | | | | +--------------------+ | | +----------------+ +----------------+ | | +---------------------+ | | | ENV: Envelope | | | | PKI: Epoch Key | | KM: KMC Public | | | | INIT_SK: Obtain sk0 | | | | Delivery sk_0 | | | | Pair pk_i, sk_i| | Key pk_kmc_j | | | +----------+----------+ | | +---------+----------+ | | +-------+--------+ +--------+-------+ | | | | | | | | | | | | v | | +------------+------+ v +----------+------+ +---------------------+ | | | +----------------------------------+ | | | DH: Offline derive | | | | | | EVOLVE: Rotation, derive new pair | | | | next epoch sk | | | | | +---------------+------------------+ | | +----------+----------+ | | | | | | | | | | | | +------------------------+------+ v | | | | | | | +---------------------+ | | | v | | | VERIFY: Check sk | | | | New encryption certificate issued | | | matches cert pubkey | | | | | | +---------------------+ +------------------------+ +------------------------------------------+ Figure 4: Mode B: Offline DH Derivation Flow Appendix B. Implementation Notes This appendix is non-normative and provides essential hints for implementers of this document. B.1. Client Signature Construction Steps When completing the auth-01 challenge, the client MUST operate as follows: 1) Compute the JWK Thumbprint of the account public key used in the newOrder request for this Order, per [RFC7638], to obtain account_thumbprint. *Code Example (Python)*: import hashlib import json import base64 def compute_account_thumbprint(jwk): # RFC 7638 requires sorting by fixed fields sorted_jwk = {k: jwk[k] for k in sorted(['kty', 'crv', 'x', 'y'])} jwk_json = json.dumps(sorted_jwk, separators=(',', ':')) return base64url_encode(hashlib.sha256(jwk_json.encode('utf-8')).digest()) Geng, et al. Expires 21 January 2027 [Page 48] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 2) Construct the signature input message = "ACME auth-01" || 0x00 || challenge_url || 0x00 || token_utf8_bytes || 0x00 || account_thumbprint. 3) Compute hash = SM3(message). 4) Generate an SM2 signature on hash using the signature private key, output as *ASN.1 DER encoding* of SEQUENCE { r INTEGER, s INTEGER }. 5) Ensure the signature satisfies the normalized form s <= n/2; if s > n/2, replace with n - s. 6) Base64url-encode the DER-encoded signature value and place it in the authSignaturefield. *Signature Construction Order Warning*: The client MUST strictly use thefield order above. Any deviation will cause server verification failure. SM2 signature encoding considerations: Clients need to use an ASN.1 DER encoding library and be aware of INTEGER encoding rules (X.690 Section 8.3.2): when the most significant bit of the integer value is 1, a leading 0x00 byte must be added. authKey Provision: The client only needs to provide the JWK-formatted authKey in the JWS Payload of the newOrder request; SubjectPublicKeyInfo encoding is performed by the server (see Section 4.1). Envelope Retrieval from finalize Response: If includeEnvelope: true was explicitly set but no envelopefield is received, it SHOULD be treated as an error and theflow terminated. When not explicitly set, the client SHOULD NOT expect the envelopefield. B.2. Server Verification Steps When verifying the auth-01 signature, the server MUST use the exact same construction method as the client. Specific steps include: 1. Obtain kid from the JWS header, look up the corresponding account public key, verify JWS signature validity, and confirm the account matches the one that created the Order. 2. Obtain the account JWK from the account state saved when creating the Order, compute account_thumbprint per [RFC7638]; do not extract this value from authSignature or the challenge response. 3. Extract the signature value from authSignature, verify that token matches the challenge object and has not been used. 4. Construct the signature input message = "ACME auth-01" || 0x00 || challenge_url || 0x00 || token_utf8_bytes || 0x00 || account_thumbprint using the account_thumbprint computed in step 2. Geng, et al. Expires 21 January 2027 [Page 49] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 5. Compute hash = SM3(message) and verify the signature using the authKey public key. 6. Verify that r and s are both in the range [1, n-1] and that s <= n/2. 7. Verify that the signing public key matches the authKey declared in newOrder. 8. Verify that the account identified by kid matches the account corresponding to authKey. If the account key has been changed before the challenge is completed, the server MUST reject the challenge response, causing the associated incomplete auth-01 authorization object and its Order to transition to invalid, and MUST NOT use the new account key's thumbprint to reconstruct the signature input for the old Order. *Cache Control*: When returning a finalize response containing the envelopefield, the server MUST set the Cache-Control: no-store, private header and ensure caching is explicitly disabled for the finalize endpoint at the CDN level. *Audit Logs*: The server SHOULD record audit logs for all encryption certificate application operations, including auth-01 challenge completion, KMC invocation results, certificate issuance records, and envelope delivery records. B.3. Relying Party Verification Procedure When verifying an encryption certificate, relying parties MUST check the sm2AuthKeyHash extension: 1. Extract the sm2AuthKeyHash extension value from the encryption certificate (if present) and parse the SM2AuthKeyHash structure. 2. If the extension is not present, the certificate does not conform to this specification (mandatory extension); the relying party MAY treat it as a foreign or historical certificate according to policy and SHOULD record it in the audit log. 3. If the extension is present, confirm that hashAlgorithm.algorithm is the standard OID for SM3 (1.2.156.10197.1.401). If unrecognizable, the relying party SHOULD reject trust in the certificate. 4. Extract the 32-byte hash value from the hashValuefield. Geng, et al. Expires 21 January 2027 [Page 50] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 5. Extract the public key from the expected signature certificate and compute its SM3 hash. 6. Compare the two for consistency. If inconsistent, the relying party MUST reject trust in the certificate and treat it as a security violation. B.4. KMC Core Hints 1. Key generation MUST use a random number generator conforming to [GMT.0078-2020], and its output MUST pass the randomness tests specified in [GMT.0005-2021]. 2. The KDF output length parameter klen MUST be set to 128 bits (SM4 key length), with specific parameters per [GMT.0003.4-2012] Section 4.2. 3. When parsing the SubjectPublicKeyInfo structure passed by the server: MUST support the primary encoding specified in Section 4.1 (SM2 algorithm OID direct identification). For interoperability with deployed systems, SHOULD be able to parse alternateSubjectPublicKeyInfo structures encoded with id- ecPublicKey + SM2 curve OID (1.2.156.10197.1.301). 4. After encryption certificate revocation or expiration, escrowed private keys SHOULD be deleted within a reasonable period; the deletion period SHOULD be clearly stated in the CP/ CPS (recommended not to exceed 30 days) and recorded in the audit log. 5. For deployments with higher requirements regarding single-point trust risk, *threshold KMC* or *key sharding* schemes are recommended; when adopting such schemes, their security model SHOULD be consistent with the threat model of this document. B.5. Historical Compatibility Notes *SM3 Alternate OID*: The standard OID for SM3 in [GMT.0006-2023] is 1.2.156.10197.1.401. Historical implementations may have used the alternate OID 1.2.156.197.1.401. Implementers SHOULD support parsing historical data using the alternate OID for validating old certificates, but MUST use the standard OID when generating new data (certificates, signatures, envelopes). Appendix C. ASN.1 Module Geng, et al. Expires 21 January 2027 [Page 51] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 SM2-KEY-ROTATION-EXTENSIONS { iso(1) member-body(2) cn(156) 10197 6 3 1 id-mod-sm2-kr-extensions(1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS EXTENSION FROM PKIX1Explicit-2009 { ... } SubjectPublicKeyInfo FROM PKIX1Implicit-2009 { ... } AlgorithmIdentifier FROM CryptographicMessageSyntax-2009 { ... } ; id-sm2-auth-key-hash OBJECT IDENTIFIER ::= { 1.2.156.10197.6.3.1 } sm2AuthKeyHash EXTENSION ::= { SYNTAX SM2AuthKeyHash IDENTIFIED BY id-sm2-auth-key-hash CRITICALITY { FALSE } } SM2AuthKeyHash ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OCTET STRING (SIZE(32)) } END Appendix D. OID Quick Reference +===============+============================+======================+ | Name | OID |Purpose | +===============+============================+======================+ | SM2 Public | 1.2.156.10197.1.301 |Asymmetric encryption | | Key | | | | Cryptosystem | | | +---------------+----------------------------+----------------------+ | SM3 | 1.2.156.10197.1.401 |*MUST be used for all | | (Standard) | |new data* | +---------------+----------------------------+----------------------+ | SM3 | 1.2.156.197.1.401 |Historical data | | (Alternate, | |validation only | | historical | | | | only) | | | +---------------+----------------------------+----------------------+ | SM4 | 1.2.156.10197.1.104 |Symmetric encryption | +---------------+----------------------------+----------------------+ | SM2-3 Public | 1.2.156.10197.1.301.3 |Digital envelope | | Key | |keyEncryptionAlgorithm| Geng, et al. Expires 21 January 2027 [Page 52] Internet-Draft ACME SM2 Dual-Certificate Rotation July 2026 | Encryption | | | +---------------+----------------------------+----------------------+ | sm2-with-SM3 | 1.2.156.10197.1.501 |auth-01 signature | | | |algorithm | +---------------+----------------------------+----------------------+ | id-sm2-auth- | 1.2.156.10197.6.3.1 |sm2AuthKeyHash | | key-hash | |extension | | (Recommended) | | | +---------------+----------------------------+----------------------+ | id-sm2-auth- | 1.3.6.1.4.1.2011.2.467.1.3 |Experimental | | key-hash | |deployment | | (Temporary) | | | +---------------+----------------------------+----------------------+ Table 10 Authors' Addresses Feng Geng Huawei Technologies Email: gengfeng@huawei.com Panyu Wu Huawei Technologies Email: wupanyu3@huawei.com Guilin Wang Huawei Technologies Email: wang.guilin@huawei.com Xin Chen TrustAsia Email: palos.chen@trustasia.com Geng, et al. Expires 21 January 2027 [Page 53]