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