ACME STAR Extension for SM2 Dual-Certificate Automated Key Rotation

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

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

• 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:¶

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

3.1. ARKG SM Cryptographic Suite

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

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:¶

(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:¶

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

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

• 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 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:¶

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

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

5.1. 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]):¶

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

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.1. Directory Object Extensions

{
  "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).¶

• 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 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:¶

{
  "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:¶

{
  "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:¶

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

• 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:¶

New Error Types Defined in 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.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 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:¶

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

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

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

• 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?¶

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

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.1. OID Allocation Recommendations

• 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

###¶

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:¶

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.

[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, <https://www.rfc-editor.org/info/rfc8555>.

[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, <https://www.rfc-editor.org/info/rfc8739>.

[RFC6962]

Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.

[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, <https://www.rfc-editor.org/info/rfc9115>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/info/rfc7638>.

[RFC5652]

Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.

[RFC9773]

Gable, A., "ACME Renewal Information (ARI) Extension", RFC 9773, DOI 10.17487/RFC9773, June 2025, <https://www.rfc-editor.org/info/rfc9773>.

12.2. Informative References

[I-D.geng-acme-public-key]

Geng, F., Wu, P., Xia, L., and C. 陈鑫, "Automated Certificate Management Environment (ACME) Extension for Public Key Challenges", Work in Progress, Internet-Draft, draft-geng-acme-public-key-07, 14 June 2026, <https://datatracker.ietf.org/doc/html/draft-geng-acme-public-key-07>.

[I-D.ietf-acme-profiles]

Gable, A., "Automated Certificate Management Environment (ACME) Profiles Extension", Work in Progress, Internet-Draft, draft-ietf-acme-profiles-01, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-acme-profiles-01>.

[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, <https://datatracker.ietf.org/doc/html/draft-bradleylundberg-cfrg-arkg-11>.

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

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

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

A.3. Mode A: Envelope Delivery Flow

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

A.4. Mode B: Offline DH Derivation Flow

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

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

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

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

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