]> Huawei Technologies

gengfeng@huawei.com

Huawei Technologies

wupanyu3@huawei.com

Huawei Technologies

wang.guilin@huawei.com

TrustAsia

palos.chen@trustasia.com

Automated Certificate Management Environment Working Group The SM2 dual-certificate system, specified in , 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 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 (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) . 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.

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.

Introduction The Automatic Certificate Management Environment (ACME) protocol 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. 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. 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 ), 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. (ACME STAR) defines automatic renewal of short-term certificates, enabling clients to obtain continuously renewed certificates without repeatedly executing the full ACME flow.

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 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.

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 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 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.

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 to complete the application.
• For the encryption certificate, this document defines an automated key rotation mechanism based on Asynchronous Remote Key Generation (ARKG) , 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.

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 and ARI 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 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 are centrally generated and escrowed by the KMC, is a mandatory requirement imposed by 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 to the specific deployment scenario of SM2 dual- certificate management in the SM ecosystem. This Profile follows the Profile framework conventions defined in . 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."

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 : The ARKG algorithm in this specification is a concrete instantiation of that generic framework on the SM2 curve.
• Based on 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 Certificate Transparency: The Merkle root for audit proofs is submitted to CT logs.
• Follows : This document, as an ACME Profile, follows the conventions of that framework.

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 (Delegated Credentials), which addresses "certificate issuance delegation"; this document addresses "key generation and escrow delegation." The differences are as follows:

Dimension	RFC 9115 (Delegated Credentials)	This Document (GM Profile)
Delegated object	Certificate issuance authority	Encryption key generation and escrow
Delegatee	Third party (e.g., CDN)	KMC (Key Management Center)
Private key holder	Delegatee holds private key	KMC generates and escrows; client holds copy
Use case	Third party applies for certificate on behalf of principal	Compliance requirement for encryption private key to be managed by KMC

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.

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 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]. New terms defined in this specification:

• ARKG: Asynchronous Remote Key Generation, as defined in . The ARKG in this specification is a concrete instantiation of the generic framework in 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 . This value provides cryptographic account public key binding in the auth-01 signature input, enabling offline auditability of the signature.

Note: JWK Thumbprint 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.

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.

ARKG SM Cryptographic Suite The ARKG SM cryptographic suite adopted by this protocol consists of the following cryptographic algorithms:

Algorithm Component	SM Algorithm	Specification Reference	Purpose
Public-key cryptosystem	SM2 (sm2p256v1 curve)	GM/T 0003-2012	Elliptic curve group operations, public/private key derivation
Hash function	SM3 (256-bit output)	GM/T 0004-2012	Seed chain, Merkle tree, signature hashing
Pseudorandom function	HMAC-SM3	GM/T 0042-2015	Derivation factor derivation (PRF)
Symmetric encryption	SM4 (128-bit key)	GM/T 0002-2012	Digital envelope encryption (Mode A)
Random number generation	RNG conforming to GM/T 0108-2021	GM/T 0108-2021	Seed generation, key derivation

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 . 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: (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 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).

Seed Chain and Key Derivation The KMC maintains a seed chain: 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: 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: seed_kmc Generation Requirements: Generation of seed_kmc MUST satisfy the following requirements:

1. Use a cryptographically secure random number generator conforming to .
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.

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.

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.

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 ( /), 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 Section 6.1).
• When using SignedAndEnvelopedData, the versionfield MUST be set to 1 (per 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 (see Section 10). This document uses this type for compatibility with . 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]).

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 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: 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: Server Computation: 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: 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 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).

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.

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.

Deployment Scenario	Recommended Mode	Rationale
Maximum compatibility with base framework required	Mode A (Envelope)	Full inheritance, zero protocol deviation
Lowest deployment risk desired	Mode A (Envelope)	Mature mechanism, already validated
Large-scale deployment (millions of certificates)	Mode B (Offline DH)	Stateless derivation, client offline
Client needs offline private key derivation	Mode B (Offline DH)	Only online for certificate retrieval
Key insulation security property required	Mode B (Offline DH)	Private key compromise does not affect other epochs
Most direct audit recovery requirement	Mode A (Envelope)	Storage is evidence
PQC migration preparation prioritized	Mode B (Offline DH)	Smoothly replaceable with PQC KEM

Both modes can coexist on the same server, and different orders may use different modes.

Protocol Flow This section borrows the three-phase structure of STAR, dividing the synchronized short-term automatic renewal process for SM2 dual certificates into three phases: Bootstrap, Auto Renewal, and Certificate Access.

Phase One: Bootstrap Step 1: Signature Certificate Authorization and Issuance 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]): 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].

Phase Two: Auto Renewal

• Signature Certificate Auto Renewal (STAR): Automatic renewal per the 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.

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.

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 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.

Directory Object Extensions

• 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).
• key-rotation-state: Directory template URL for the state resource.### 6.2. Creation of Encryption Certificate Orders

Creation of Encryption Certificate Orders 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 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.
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: 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 ). The key rotation lifecycle is managed by the independent key-rotation-state resource.

Key Rotation State Resource and State Transitions The state machine of this resource maintains semantic consistency with STAR's () auto-renewal state machine—the canceled state cancels the rotation process, not the already-issued certificate. State Resource: 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 . State Transitions:

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/canceled	→ none	Terminal states

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).

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.
• 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.

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.

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.

Error Handling Base Framework Error Types:

Error Type	HTTP Status	Description
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 Section 6.7
urn:ietf:params:acme:error:signingCertRequired	403	No valid signature certificate found corresponding to authKey

New Error Types Defined in This Specification

Error Type	HTTP Status	Description
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

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.

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 .

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.

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.

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).

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.

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 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.

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.

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:

• 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.

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.

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.

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 , leading to complex error handling and state management logic.
• Two-Order Model (Selected): Creates independent Orders for each certificate, strictly ollowing the resource model of , 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.

Key Rotation State Resource vs. Order Extension Fields Question: Should key rotation status be managed directly as extensionfields of the Order? Consideration: In , an Order enters the valid terminal state and does not change thereafter. STAR () 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 while providingfine-grained control over the key rotation process.

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.
• 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.

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 . 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.

Cancellation Semantics Alignment with STAR vs. Custom Question: Should the cancellation semantics of the key rotation state align with STAR's cancellation semantics? Consideration: STAR's () 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.

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.

Future Considerations

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 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.

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.

KMC Public Key Rotation Mechanism A standardized rotation protocol for pk_kmc[j] may be defined in the future.

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 (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.

IANA and SM Ecosystem Deployment Considerations

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

• 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

ACME Registry Entries ###

Registry	Field Name	Type	Description
ACME Directory Object Fields	key-rotation	object	Contains supportedModes, supportedSyncModes, supportedAlgorithms, maxEpochDuration, minEpochDuration
ACME Directory Object Fields	key-rotation-state	string	Directory template URL for state resource
ACME Order Object Fields	key-rotation	object	Contains algorithm, derivationMode, seedSync, initialEpoch, syncWith
ACME Resource Types	key-rotation-state	/acme/key-rotation-state/{id}	Key rotation state resource
ACME Resource Types	key-rotation-envelope	/acme/key-rotation-state/{id}/envelope	Envelope endpoint (Mode A)
ACME Resource Types	key-rotation-kmc-public-key	/acme/key-rotation-state/{id}/kmc-public-key	KMC public key endpoint (Mode B)

Note: authKey and includeEnvelope are already registered in the base framework [I-D.geng-acme-sm2dualcert-extension]; auto-renewal is already registered in .

Algorithm Identifier Registration Establish an algorithm identifier registration mechanism in the SM ecosystem. Initial registration items:

Identifier	Curve	Hash Algorithm	Corresponding OID	Purpose
sm2p256v1-sm3	sm2p256v1	SM3	1.2.156.10197.1.301 / 1.2.156.10197.1.401	Currently only supported combination

References Normative References State Cryptography Administration State Cryptography Administration State Cryptography Administration State Cryptography Administration State Cryptography Administration State Cryptography Administration State Cryptography Administration Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates. This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This document defines a profile of the Automatic Certificate Management Environment (ACME) protocol by which the holder of an identifier (e.g., a domain name) can allow a third party to obtain an X.509 certificate such that the certificate subject is the delegated identifier while the certified public key corresponds to a private key controlled by the third party. A primary use case is that of a Content Delivery Network (CDN), the third party, terminating TLS sessions on behalf of a content provider (the holder of a domain name). The presented mechanism allows the holder of the identifier to retain control over the delegation and revoke it at any time. Importantly, this mechanism does not require any modification to the deployed TLS clients and servers. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document specifies how an Automated Certificate Management Environment (ACME) server may provide suggestions to ACME clients as to when they should attempt to renew their certificates. This allows servers to mitigate load spikes and ensures that clients do not make false assumptions about appropriate certificate renewal periods. Informative References Huawei Technologies Huawei Technologies Huawei Technologies TrustAsia The Automatic Certificate Management Environment (ACME) [RFC8555] requires a PKCS#10 Certificate Signing Request (CSR) at the finalization stage. This document defines a new ACME challenge type, "pk-01", that allows a client to prove possession of a private key directly, without constructing a CSR. The primary motivation is to support key types that cannot generate CSR self-signatures, notably post-quantum Key Encapsulation Mechanism (KEM) keys. The client declares the public key via a popKey field in the "newOrder" request; the server attaches the "pk-01" challenge to existing identifier authorizations. When all required authorizations are satisfied, the ACME server issues a certificate using the validated public key and the authorized identifiers, eliminating the need for a CSR in the finalization stage. Internet Security Research Group This document defines how an ACME Server may offer a selection of different certificate profiles to ACME Clients, and how those clients may indicate which profile they want. Yubico Yubico Asynchronous Remote Key Generation (ARKG) is an abstract algorithm that enables delegation of asymmetric public key generation without giving access to the corresponding private keys. This capability enables a variety of applications: a user agent can generate pseudonymous public keys to prevent tracking; a message sender can generate ephemeral recipient public keys to enhance forward secrecy; two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other. This document provides three main contributions: a specification of the generic ARKG algorithm using abstract primitives; a set of formulae for instantiating the abstract primitives using concrete primitives; and an initial set of fully specified concrete ARKG instances. We expect that additional instances will be defined in the future.

Protocol Interaction Diagrams

Global Dual-Certificate Flow (Three-Phase)

Global Dual-Certificate Flow (Three-Phase) | | | | | | 2. Return Order + authorization challenges | | |<---------------------------------------------| | | | | | 3. Complete all authorization challenges | | |--------------------------------------------->| | | | | | 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: Mode A: Fetch private key via envelope endpoint Note over Client: Mode B: Derive private key offline locally ]]>

ARKG Key Derivation Layer

ARKG Key Derivation Layer | | | | +------------+ +-----------+----------+ | | | | | +---------------+----------------+ | | | | | | v v | | +------------------+ +----------------+ | | CRED: cred_i | | PKM: KMC pubkey| | | Derivation Factor| | pk_kmc_j | | +--------+---------+ +----------------+ | | | | v | | +--------------------+ | | | PKI: Epoch key pair | | | | pk_i, sk_i | | | +--------------------+ | | | +------------------------------------------------------+ ]]>

Mode A: Envelope Delivery Flow

Mode A: Envelope Delivery Flow | 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 ]]>

Mode B: Offline DH Derivation Flow

Mode B: Offline DH Derivation Flow

Implementation Notes This appendix is non-normative and provides essential hints for implementers of this document.

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 , to obtain account_thumbprint. Code Example (Python): 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.

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 ; 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.
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.

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.
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.

KMC Core Hints

1. Key generation MUST use a random number generator conforming to , and its output MUST pass the randomness tests specified in .
2. The KDF output length parameter klen MUST be set to 128 bits (SM4 key length), with specific parameters per 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.

Historical Compatibility Notes SM3 Alternate OID: The standard OID for SM3 in 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).

ASN.1 Module

OID Quick Reference

Name	OID	Purpose
SM2 Public Key Cryptosystem	1.2.156.10197.1.301	Asymmetric encryption
SM3 (Standard)	1.2.156.10197.1.401	MUST be used for all new data
SM3 (Alternate, historical only)	1.2.156.197.1.401	Historical data validation only
SM4	1.2.156.10197.1.104	Symmetric encryption
SM2-3 Public Key Encryption	1.2.156.10197.1.301.3	Digital envelope keyEncryptionAlgorithm
sm2-with-SM3	1.2.156.10197.1.501	auth-01 signature algorithm
id-sm2-auth-key-hash (Recommended)	1.2.156.10197.6.3.1	sm2AuthKeyHash extension
id-sm2-auth-key-hash (Temporary)	1.3.6.1.4.1.2011.2.467.1.3	Experimental deployment