ACME Extension for SM2 Dual-Certificate System

1.1. About the Nature of This Document

This document is intended to be Informational and aims to document how the ACME protocol can be extended to support automated management of SM2 dual certificates in the GM certificate system.¶

This document does not represent IETF consensus and is not an IETF standard. The technical solution described herein is applicable only to deployment scenarios of dedicated trust systems that comply with the GM/T series of standards.¶

The normative language used in this document (e.g., "MUST," "SHALL") is intended to ensure interoperability between different implementations in the GM-specific deployment scenarios described herein and is not intended to establish a global Internet standard.¶

This document does not standardize the SM2 cryptographic algorithm or any other cryptographic primitive. All cryptographic algorithms referenced in this document are defined in existing GM/T standards [GMT.0006-2023] and are cited normatively only for the purpose of specifying the ACME protocol adaptation for environments where these algorithms are already deployed. Algorithm standardization, including the registration of SM2-related identifiers in IANA registries such as the “JSON Web Key Elliptic Curve” registry, is addressed in this document only to the extent necessary for ACME protocol interoperability and does not constitute a general standardization of the SM2 algorithm suite.¶

1.2. Background

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 certified, the authorizations that must be completed, and the final certificate URL.¶

In the China's Commercial Cryptography certificate system (defined in [GMT.0034-2014]), the SM2 dual-certificate architecture is adopted: each entity holds a signature certificate (for identity authentication and digital signatures) and an encryption certificate (for data encryption and key agreement). The two certificates are issued to the same entity but serve different security purposes and are subject to different key management policies.¶

A notable feature of the SM2 dual-certificate system is that the encryption private key is generated by the Key Management Center (KMC) and securely delivered to the end entity. The KMC encrypts the encryption private key using the entity's signature public key via a digital envelope (as defined in [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.¶

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

This document aims to fill this gap by providing an ACME-compliant automated issuance solution for SM2 dual certificates.¶

1.4. Problem Statement

Currently, the standard ACME workflow faces three key challenges in the SM2 dual-certificate use case:¶

1. Generation and distribution of the encryption private key: Standard ACME requires the client to generate the key pair, whereas the SM2 encryption certificate requires the KMC to generate and escrow the encryption private key, necessitating a secure distribution mechanism.¶

2. Association between the signature certificate and the encryption certificate: The two certificates belong to the same entity and require a verifiable binding within the ACME framework.¶

3. Operational bottleneck for large-scale deployment: The application, renewal, and deployment of SM2 certificates still require manual intervention. As issuance volume grows, manual management can lead to uncontrolled operational costs and frequent certificate expiration incidents and cannot adapt to continuously shortening certificate validity periods.¶

1.5. Solution Overview

This document addresses these three challenges as follows:¶

• For the signature certificate, the standard ACME workflow is fully reused; the client may use the traditional CSR approach or the pk-01 challenge [I-D.geng-acme-public-key]. If the pk-01 challenge is unavailable, the client SHOULD fall back to the standard CSR approach.¶

• For the encryption certificate, a new challenge type, auth-01, is defined specifically for the identity authorization scenario. The client proves possession of the signature private key to authorize the KMC to generate an encryption key pair on its behalf. This challenge type intrinsically binds the issuance of the encryption certificate to the signature key, requiring no additional binding identifiers.¶

Without introducing new Order types, this design maintains compatibility with existing ACME clients and servers and converges all SM2 dual-certificate logic to the auth-01 challenge and a small set of extension fields such as authKey.¶

About Extension Parameter Passing: This document passes extension parameters (authKey, includeEnvelope) in the JWS Payload of the newOrder request. This is the standard extension mechanism for the ACME protocol, consistent with the newOrder request format defined in [RFC8555] Section 7.4. All extension parameters are protected by the JWS signature, ensuring their integrity and authenticity. Standard ACME servers that do not recognize these fields will ignore them, ensuring backward compatibility.¶

1.6. Scope and Positioning

Note on Key Escrow Positioning: 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 the encryption private key is centrally generated and escrowed by the KMC, is a mandatory requirement imposed by [GMT.0034-2014] and related regulatory frameworks for encryption certificates. This document merely provides an ACME protocol-level adaptation for this established regulatory fact and does not constitute a general recommendation for key escrow architectures, nor does it alter the principle that the signature certificate private key must be generated by the client and remain within its trust boundary.¶

The extension mechanism described in this document is applicable only to dedicated trust systems that comply with GM/T series standards. This document is not applicable to public-trust TLS certificate systems such as the Web PKI governed by the CA/Browser Forum.¶

Note on Terminology: The term “dual-certificate system” in this document refers specifically to the SM2 architecture defined in [GMT.0034-2014], where two certificates (signature and encryption) are issued to the same entity with distinct key usages, and the encryption private key is generated and escrowed by a Key Management Center (KMC). This is distinct from other “dual-certificate” or “dual-key” scenarios previously discussed in the IETF context, such as S/MIME dual-use certificates [I-D.ietf-acme-smime] where separate signature and encryption certificates are managed for email purposes. The trust model, key management requirements, and regulatory basis of the SM2 dual-certificate system differ significantly from those scenarios, and this document does not address S/MIME or other email certificate use cases.¶

3.1. Creating Two Separate Orders

To request both the signature certificate and the encryption certificate simultaneously, the client creates two separate Orders following the steps defined in [RFC8555] Section 7.4. These two Orders MUST satisfy the following requirements:¶

• They MUST be authenticated using the same ACME account key.¶

• Their identifiers fields MUST contain the same identifiers (e.g., the same domain name or device ID).¶

Signature Key Pair Generation Constraint: Per [GMT.0034-2014], the signature key pair MUST be generated by the client. The ACME server MUST NOT generate the signature key pair on behalf of the client.¶

Encryption Key Pair Generation Constraint: Per {GMT.0034-2014}}, the encryption key pair MUST be generated by the KMC. The client MUST NOT generate the encryption key pair for the encryption certificate requested under this specification.¶

Issuance Order Dependency: The two Orders are independent at the account and identifier levels, but the finalize processing of the encryption certificate Order depends on the corresponding signature certificate having been issued and being valid (see the signature certificate existence check in Section 3.3.2). Therefore, the client MUST complete issuance of the signature certificate before submitting the finalize request for the encryption certificate Order; otherwise, the finalize request for the encryption certificate Order will fail with signingCertRequired and the Order will transition to invalid. The identifier authorizations for the two Orders may be completed in parallel; only the finalize step has this sequential dependency.¶

3.2. Signature Certificate Request Flow

The signature certificate request fully follows the standard ACME workflow. The client may choose either of the following options:¶

Option 1: Standard CSR Approach¶

1. The client creates an Order.¶

2. The client completes the required authorization challenges (e.g., HTTP-01, DNS-01).¶

3. The client submits a CSR containing the signature public key to the finalize endpoint.¶

4. The server validates the CSR and issues the signature certificate.¶

Option 2: Using the pk-01 Challenge (Optional)¶

This option is an optimization. The client SHOULD use the standard CSR approach as the primary method. If the server and client support the pk-01 challenge defined in [I-D.geng-acme-public-key], the client may use this challenge to bypass CSR submission. If pk-01 is unavailable, the client MUST fall back to the standard CSR approach:¶

1. The client declares the signature public key via the popKey field in the newOrder request.¶

2. The server returns the pk-01 challenge, and the client completes it using the signature private key.¶

3. Upon successful challenge completion, the client submits an empty finalize request ({}), and the server issues the signature certificate containing that public key.¶

Regardless of which approach is used, the KeyUsage extension of the signature certificate MUST comply with Section 3.4.¶

The scope distinction between pk-01 and auth-01 is as follows: pk-01 is only for signature certificate requests, auth-01 is only for encryption certificate requests, and the two MUST NOT be mixed in the same Order.¶

3.3. Encryption Certificate Request Flow

The encryption certificate request uses the auth-01 challenge type defined in this document, which is specifically designed for identity authorization scenarios.¶

{
    "type": "auth-01",
    "url": "https://example.com/acme/chall/123",
    "token": "q9K3xwLmZ2VtT7cPnE8fRaYb01UgHdSJ",
    "status": "pending"
}

{
    "type": "auth-01",
    "authSignature": "base64url(signature_bytes)"
}

message = "ACME auth-01" || 0x00 || challenge_url || 0x00 || token_utf8_bytes || 0x00 || account_thumbprint

{
    "identifiers": [{"type": "dns", "value": "example.com"}],
    "authKey": {
        "kty": "EC",
        "crv": "sm2p256v1",
        "x": "...",
        "y": "..."
    },
    "includeEnvelope": true
}

{
    "status": "valid",
    "expires": "...",
    "identifiers": [{"type": "dns", "value": "example.com"}],
    "authorizations": ["https://example.com/acme/authz/456"],
    "finalize": "...",
    "certificate": "...",
    "envelope": "base64url(ASN.1 DER of digital envelope)"
}

4.1. SubjectPublicKeyInfo Encoding of the Signature Public Key (Server-to-KMC Interface)

Before triggering the KMC, the server MUST deterministically convert the authKey (in JWK format) from the newOrder request to a SubjectPublicKeyInfo structure (defined in [RFC5280]) and pass it to the KMC. The specific encoding requirements are as follows:¶

• The algorithm field MUST be id-ecPublicKey (OID: 1.2.840.10045.2.1, defined in [RFC5480]).¶

• The parameters field MUST be encoded as an OBJECT IDENTIFIER type with the value of the SM2 curve OID 1.2.156.10197.1.301 (defined in [GMT.0003.5-2012]). The parameters field MUST NOT be encoded as NULL or omitted.¶

• The subjectPublicKey field MUST be the uncompressed point encoding of the SM2 public key (0x04 || x || y, 32 bytes each), conforming to [RFC5480] Section 2.2 and [GMT.0015-2023].¶

The KMC uses this public key to encrypt the encryption private key via a digital envelope compliant with [GMT.0010-2023].¶

SubjectPublicKeyInfo Encoding Compatibility:¶

When parsing this structure, the KMC MUST give priority to the [RFC5480] compliant encoding (id-ecPublicKey + SM2 curve parameters). Some legacy implementations may use the SM2 algorithm OID directly for identification; during the transition period, the KMC MAY recognize and process this encoding variant to support interoperability with existing deployments, but this specification RECOMMENDS phasing out support for the alternative encoding in new implementations. When generating this structure, the server MUST use the RFC 5480-compliant encoding and MUST NOT use the SM2 algorithm OID directly.¶

4.2. sm2AuthKeyHash Extension

The sm2AuthKeyHash extension is used in encryption certificates to record the SM3 hash of the authorizing signature public key and its algorithm identifier.¶

The ASN.1 syntax is:¶

sm2AuthKeyHash EXTENSION ::= {
SYNTAX SM2AuthKeyHash
IDENTIFIED BY id-sm2-auth-key-hash
}
SM2AuthKeyHash ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier, -- hash algorithm identifier (currently SM3)
hashValue OCTET STRING -- hash value
}

The fields are defined as follows:¶

• hashAlgorithm: An AlgorithmIdentifier structure. It MUST currently be the SM3 algorithm: the algorithm field is the standard OID for SM3 (1.2.156.10197.1.401, defined in [GMT.0006-2023]). When generating, the parameters field SHOULD be encoded as NULL; when parsing, implementations MUST be able to parse NULL and SHOULD also support omission of the parameters field.¶

• hashValue: A 32-byte OCTET STRING containing the SM3 hash of the authorizing signature public key.¶

Criticality Flag: This extension MUST be marked as non-critical (critical = FALSE).¶

Authoritativeness of the Extension: The sm2AuthKeyHash extension is the authoritative basis for the binding in the GM dual-certificate system. Relying parties MUST verify the presence and hash consistency of this extension when validating encryption certificates issued under this specification. If the extension is present and the hash does not match, the relying party MUST treat it as a security violation and reject the encryption certificate.¶

Extension Inclusion Policy: Encryption certificates issued under this specification MUST include this extension.¶

OID Assignment: The OID for this extension (id-sm2-auth-key-hash) uses the temporary OID 1.3.6.1.4.1.2011.2.467.1.3 during the standardization phase. Upon standardization, a permanent OID will be requested under 1.2.156.10197.6.3.1 (within the certificate extension arc of [GMT.0015-2023]), subject to confirmation of availability with the CCSTC.¶

5.1. New ACME Challenge Type

IANA is requested to register the following new challenge type in the "ACME Validation Methods" registry (established by [RFC8555] Section 9.7.8):¶

Description: Identity authorization challenge used to prove possession of the signature private key for the purpose of requesting an encryption certificate. Applicable Scenarios: Only for encryption certificate requests, proving that the client possesses the signature private key to authorize the KMC to generate an encryption key pair. Not applicable to signature certificate requests.¶

Note: The identifier type dns is used solely as a placeholder; the auth-01 challenge itself does not validate control over that identifier.¶

Versioning Strategy: The 01 in auth-01 indicates the current version. If incompatible changes occur in the future (e.g., signature algorithm changes or major challenge flow modifications), a new challenge type name (e.g., auth-02) will be used. Compatible extensions (e.g., new optional fields) will be handled through existing mechanisms without changing the challenge type name.¶

Future Extension Reservation: The "dedicated authorization object" design pattern in this document may serve as a reference for other ACME extensions requiring non-identifier-based authorization.¶

5.2. New ACME Error Types

IANA is requested to register the following new error types in the "ACME Error Types" registry:¶

Note: invalidCSR is complementary to the badCSR error type defined in RFC 8555. badCSR is used for CSR format or signature verification failures in signature certificate Orders, while invalidCSR is used for violations of this specification's semantics.¶

5.3. Certificate Extension OID Assignment (Non-IANA Matter)

The permanent OID for the certificate extension id-sm2-auth-key-hash defined in this document falls under the 1.2.156.10197 arc managed by the CCSTC. This arc is not within IANA's management scope; therefore, this document DOES NOT submit an OID registration request to IANA.¶

5.4. Transition Period and OID Migration

During the transition from temporary OIDs to permanent OIDs, implementations MUST accept both temporary and permanent OID values. The specific migration plan is as follows:¶

Phase 1: Coexistence Period (0-12 months after permanent OID assignment): Servers MUST accept both temporary and permanent OIDs, SHOULD use permanent OIDs for new certificate issuance; clients MUST be able to parse certificates containing either temporary or permanent OIDs.¶

Phase 2: Permanent OID Only Period (12 months after permanent OID assignment): Servers SHOULD accept only permanent OIDs (but may still be configured to accept temporary OIDs to support transition) and MUST use only permanent OIDs for new certificate issuance.¶

Certificates issued during the temporary OID transition period remain valid for their full validity period; certificate holders SHOULD re-issue certificates using permanent OIDs upon renewal.¶

5.5. JOSE Registration

IANA is requested to register the following curve in the "JSON Web Key Elliptic Curve" registry (established by [RFC7518]):¶

This document does not register a JWS signature algorithm identifier: the signature value for the auth-01 challenge is carried in the authSignature field as base64url, not via the JWS alg mechanism; the JWS alg registration required for ACME account keys using the SM2 algorithm is to be addressed by companion documents.¶

5.6. ACME Order Object Field Registration

IANA is requested to register the following fields in the "ACME Order Object Fields" registry (established by [RFC8555] Section 9.7.2):¶

6.1. KMC Infrastructure Security

KMC Signature Certificate Trust Anchor: The KMC MUST use a signature certificate issued by a CA (and MUST NOT use a self-signed certificate or an uncertified key) to sign the signedAndEnvelopedData (if that type is used). The client SHOULD verify the KMC's signature certificate chain by configuring a trust anchor (consistent with the trust anchor used to validate the encryption certificate). It is RECOMMENDED that the KMC signature certificate and the encryption certificate be issued by the same CA. If issued by different CAs, the ACME server SHOULD provide the KMC signature certificate trust anchor's retrieval address in the directory object (e.g., via a "kmc-trust-anchor" field). The client MUST use the "kmc-trust-anchor" field provided in the directory object to validate the KMC signature certificate chain.¶

KMC Signature Certificate Lifecycle Management: The renewal window for the KMC signature certificate SHOULD be at least 30 days. The KMC SHOULD establish an automatic renewal mechanism. If the KMC signature certificate is nearing expiration (remaining validity less than 30 days), the KMC SHOULD log a warning in the audit log.Emergency Handling: If the KMC signature certificate expires unexpectedly, the KMC SHOULD re-sign generated digital envelopes with a new valid certificate or notify the client to re-initiate the encryption certificate request.¶

KMC-ACME Server Communication Security: Communication between the ACME server and the KMC MUST use mutually authenticated mTLS, following the provisions of Section 6 of [GMT.0014-2023]. Both parties MUST use certificates stored in hardware cryptographic modules for authentication. When returning the digital envelope to the ACME server, the KMC MUST sign the envelope using its signature certificate (i.e., using the signedAndEnvelopedData type). The ACME server MUST verify the KMC's signature before forwarding the envelope to the client. Both communicating parties SHOULD log all mTLS connection audit records.¶

6.2. Key Usage Separation

Per [GMT.0034-2014], signature keys and encryption keys serve different purposes. The client's signature private key is only used for ACME account authentication, signing in auth-01 challenges, and decrypting the digital envelope. The signature private key MUST NOT be used for data encryption or decryption operations. The encryption private key is only used for data encryption and decryption.¶

The server MUST verify that there is no direct association between the private key used for the auth-01 challenge and the public key in the final encryption certificate, and MUST NOT use the signature public key from authKey as the public key for the encryption certificate.¶

6.3. Challenge Signature Security

The signature input for the auth-01 challenge is a four-element tuple: the domain separation prefix "ACME auth-01" || 0x00, the challenge URL, the challenge token, and the account public key fingerprint. The prefix distinguishes this signature from other protocols; the challenge URL and token ensure the uniqueness and freshness of the challenge instance; the account public key fingerprint provides cryptographic account binding, enabling offline auditability of the signature. The challenge response itself must be submitted via ACME account key-authenticated JWS.¶

The client and server MUST use exactly the same field order and separators when constructing the signature input: "ACME auth-01" || 0x00 || challenge_url || 0x00 || token_utf8_bytes || 0x00 || account_thumbprint. Any deviation will cause signature verification to fail.¶

The account_thumbprint is fixed when the Order is created. The server reconstructs it from the account state stored with that Order and does not extract it from the challenge response or signature value. If the account key is changed before challenge completion, the server MUST invalidate the affected incomplete Order as specified in Section 3.3.2.¶

6.4. Digital Envelope and Data Protection

The digital envelope uses SM4 symmetric encryption (128-bit key) and SM2 asymmetric encryption (sm2p256v1 curve). Use of the signedAndEnvelopedData type is RECOMMENDED, and the client MUST verify the signature. The random number generator used by the KMC to generate encryption key pairs MUST comply with GM/T 0078-2020 and pass the randomness tests specified in [GMT.0005-2021].¶

When returning a finalize response containing the envelope field, the server MUST ensure that the endpoint is not cached in any caching architecture. Deployments SHOULD explicitly disable caching via CDN configuration and apply application-layer protection to the envelope field content.¶

The envelope field is delivered only when the client explicitly sets includeEnvelope: true (default false); the server MUST NOT return the envelope field when the client has not explicitly requested it. If the client did not request the envelope but later needs the encryption private key, it SHOULD re-initiate the encryption certificate request with includeEnvelope: true. Re-requesting will generate a new encryption certificate and escrowed key pair: the CA SHOULD associate encryption certificates of the same entity via authKey and revoke previously issued encryption certificates that are still valid upon re-issuance. The CA SHOULD revoke the superseded encryption certificate and SHOULD apply rate limiting to repeated requests from the same entity.¶

6.5. Intrinsic Binding and Relying Party Verification

Through the auth-01 challenge, the encryption certificate and the signature certificate establish an intrinsic cryptographic binding. The server MUST record the authorization information (hash of the signature public key) in the sm2AuthKeyHash certificate extension. Relying parties MUST check the presence and validity of this extension when validating encryption certificates.¶

The relying party verification flow is described in Appendix B.3. If the extension is absent, the certificate does not conform to this specification; if the extension is present and the hash does not match, the relying party MUST reject the encryption certificate.¶

6.6. KMC Compliance and Certificate Revocation

KMC Separation of Duties and Single Point of Trust Model: As a trusted subsystem of the CA, the KMC's operations MUST be subject to the CA's overall audit and compliance framework. There SHOULD be a separation of duties between the KMC and the CA —the CA is responsible for certificate issuance, and the KMC is responsible for key escrow, with mutual checks and balances. The KMC's key escrow operations SHOULD be included in the CA's annual WebTrust or SOC 2 audit scope. The KMC holds all encryption private keys, constituting a high-value attack target. For deployments with higher requirements regarding single point of 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.¶

Certificate Revocation Linkage Policy: The CA SHOULD define a linkage policy for revoking signature and encryption certificates. When a signature certificate is revoked, the CA SHOULD consider revoking the corresponding encryption certificate; when an encryption certificate is revoked, the signature certificate MAY remain unaffected. The revocation linkage policy SHOULD be clearly stated in the CA's CP/CPS.¶

Note: The audit and CRL/OCSP publication mechanisms for revocation linkage policies SHOULD be clearly specified in the CA's CP/CPS. If revocation of a signature certificate triggers revocation of an encryption certificate, it is RECOMMENDED that the decision rationale be recorded in the audit log for subsequent traceability.¶

Escrowed Private Key Deletion Policy: When an encryption certificate is revoked, expires, or is superseded by a newly requested certificate, the KMC SHOULD delete the corresponding escrowed encryption private key within a reasonable timeframe (30 days is RECOMMENDED), unless laws or regulations require a longer retention period.¶

Compliance: Deployments in SM trust systems SHOULD comply with the Cryptography Law, the Cybersecurity Law, [GBT.39786-2021], and relevant industry standards.¶

7.1. Dual-Order Model vs. Single-Order Model

The SM2 dual-certificate system requires the simultaneous issuance of two certificates with different purposes (signature and encryption) for the same entity. Within the ACME protocol framework, two main design paths exist:¶

• Single-Order Model: Request both certificates in a single Order, completing all authorizations and issuance in one go. While this approach appears to reduce the number of HTTP round trips, it deviates from the core semantics of RFC 8555, where an Order corresponds to a single certificate, and contradicts the long-standing consensus in the ACME community, leading to complex error handling and state management logic.¶

• Dual-Order Model (Selected): Create separate Orders for each certificate, strictly adhering to RFC 8555's resource model. The signature certificate Order reuses the standard ACME workflow; the encryption certificate Order completes identity authorization through the new auth-01 challenge. This choice maintains maximum compatibility with existing ACME clients and servers, achieves clear error isolation, and ensures long-term maintainability and extensibility of the solution.¶

7.2. Authorization Object Reuse vs. New Order-Level Field

Two approaches were considered for carrying identity authorization within the ACME framework.¶

Option A: Dedicated Authorization Object with auth-01 Challenge (Selected)¶

This approach reuses RFC 8555's existing authorization and challenge infrastructure without introducing new resource types. The dedicated authorization object follows the standard state machine (pending → valid/invalid), and its special nature—not counting toward identifier authorization reuse—is enforced by server policy, not by protocol modification.¶

Option B: New Order-Level Field (e.g., identityAuthorizations)¶

This approach would introduce a new field at the Order level, separating identity authorization from identifier authorization at the data model level. While architecturally cleaner in terms of semantic separation, it carries significant costs:¶

• Requires defining new resource types with their own lifecycle and state management.¶

• Increases implementation burden and adoption barriers for both servers and clients.¶

• Breaks the "minimal extension footprint" narrative of this document.¶

Rationale for Selected Approach¶

Option A is selected because it achieves the functional goal—requiring both identifier and identity authorization before an encryption certificate Order can be finalized—while maximizing reuse of the existing RFC 8555 resource model. The semantic distinction is enforced by server policy, not by state machine modification. This allows the extension to operate within the RFC 8555 framework without altering core protocol semantics.¶

The dedicated authorization object pattern also serves as a reusable template for other ACME extensions requiring non-identifier-based authorization or multiple independent authorization factors within a single Order (see Design Note in Section 3.3.2).¶

7.3. Identity Authorization vs. Identifier Authorization

[GMT.0034-2014] requires the encryption private key to be generated by the KMC, which necessitates proof that the requester possesses the corresponding signature private key before issuing the encryption certificate. Placing the auth-01 challenge in the same authorization object as identifier authorization challenges would conflict with RFC 8555's authorization state machine. Therefore, this document chooses to place auth-01 in a separate, dedicated authorization object, with its identifier serving only as a placeholder. This design equivalently achieves the requirement that "both identifier authorization and identity authorization must be completed" without modifying the [RFC8555] authorization state machine.¶

7.4. Envelope Delivery and Explicit Opt-In

The digital envelope (containing the encryption private key) is returned synchronously in the finalize response, ensuring that the certificate and private key are produced and delivered in the same atomic operation. The default value of includeEnvelope is set to false, requiring the client to explicitly request envelope delivery by setting includeEnvelope: true, following the security principle of least exposure.¶

7.5. Auditability of Key Escrow

Key escrow has historically been controversial within the IETF community. The mechanism described here is a mandatory requirement of [GMT.0034-2014] and related regulatory frameworks for encryption certificates. This document provides an ACME protocol adaptation for that established requirement and does not constitute a general recommendation for key escrow architectures.¶

This design provides two safeguards intended to make key escrow auditable and verifiable in the SM context:¶

• Cryptographic Binding: The auth-01 challenge and sm2AuthKeyHash extension establish a verifiable binding between the encryption certificate and the signature certificate. A relying party can extract sm2AuthKeyHash, compute the SM3 hash of the expected signature-certificate public key as specified in Section 4.2, and compare the values.¶

• Separation of Duties: The CA is responsible for certificate issuance and the KMC for key escrow. KMC escrow operations SHOULD be included in the CA's annual WebTrust or SOC 2 audit scope. Where the KMC is operated by a third party, the responsibility boundary and compliance allocation between the CA and KMC SHOULD be clearly defined.¶

Outside the SM context, recording a cryptographic commitment to an authorizing key in a credential may also provide an auditable pattern for other third-party-generated credentials.¶

8.1. General Model as a "Key Escrow Certificate Profile"

The core pattern of this document, in which an authorizing key proves possession through a cryptographic challenge and the authorized certificate records a hash of that key, can be generalized as a "Key Escrow Certificate Profile" for scenarios in which a third party generates a private key and issues a credential.¶

Post-Quantum Cryptography (PQC) Migration: A central problem in PQC migration is transferring trust from established certificates to newly issued PQC certificates. An auth-01-like challenge could allow an entity to prove possession of a traditional private key and authorize issuance of a PQC certificate. The sm2AuthKeyHash pattern could similarly be generalized into a certificate-association verification mechanism. This workflow-level trust-transfer model is complementary to algorithm-combination work in the LAMPS Working Group.¶

Device Certificates and Code Signing: Device manufacturers or code-signing CAs could use a similar mechanism to verify device or developer identity keys before issuing corresponding credentials. In an IoT manufacturing scenario, a manufacturer key could authorize issuance of device certificates.¶

8.2. Synergy with the ACME Extension Ecosystem

The dedicated-authorization-object approach in this document is intended as a reusable pattern for ACME extensions that require non-identifier-based authorization or multiple authorization factors without modifying the [RFC8555] Order state machine. Registration of new configurable fields through the "ACME Order Object Fields" registry is also intended as a standardization path for subsequent ACME extensions.¶

9.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 0034-2014 , 2023.

[GMT.0006-2023]

State Cryptography Administration, "Cryptographic Application Identifier Specification", GM/T 0006-2023 , 2023.

[GMT.0003.4-2012]

State Cryptography Administration, "SM2 Elliptic Curve Public Key Cryptography Algorithm Part 4: Public Key Encryption Algorithm", GM/T 0003.4-2012 , 2012.

[GMT.0002-2012]

State Cryptography Administration, "SM4 Block Cipher Algorithm", GM/T 0002-2012 , 2012.

[GMT.0078-2020]

State Cryptography Administration, "Design Guide for Cryptographic Random Number Generation Modules", GM/T 0078-2020 , 2020.

[GMT.0005-2021]

State Cryptography Administration, "Randomness Test Specification", GM/T 0005-2021 , 2021.

[GMT.0003.5-2012]

State Cryptography Administration, "SM2 Elliptic Curve Public Key Cryptography Algorithm Part 5: Parameter Definition", GM/T 0003.5-2012 , 2012.

[GMT.0015-2023]

State Cryptography Administration, "Digital Certificate Format Specification Based on SM2 Cryptographic Algorithm", GM/T 0015-2023 , 2023.

[GMT.0014-2023]

State Cryptography Administration, "Digital Certificate Authentication System Cryptographic Protocol Specification", GM/T 0014-2023 , 2023.

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

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

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC5480]

Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <https://www.rfc-editor.org/info/rfc5480>.

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/info/rfc7518>.

9.2. Informative References

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

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

[I-D.ietf-acme-profiles]

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

[GBT.39786-2021]

State Administration for Market Regulation, "Information Security Technology — Basic Requirements for Cryptographic Application in Information Systems", GB/T 39786-2021 , 2021.

[GBT.32918.5]

State Cryptography Administration, "Information security technology — SM2 elliptic curve public-key cryptography algorithm — Part 5: Parameter definition", GB/T 32918.5 , 2017.

A.1. Signature Certificate Order Flow (Standard CSR Approach)

Client                      ACME Server
    |                               |
    | 1. newOrder                   |
    | (identifiers + account auth)  |
    |------------------------------>|
    |                               |
    | 2. Return Order & challenges  |
    |<------------------------------|
    |                               |
    | 3. Complete auth challenges   |
    |------------------------------>|
    |                               |
    | 4. Authorization completed    |
    |<------------------------------|
    |                               |
    | 5. finalize (CSR with pubkey)
    |------------------------------>|
    Note: Server validates CSR, issues signature certificate
    |                               |
    | 6. Return certificate URL     |
    |<------------------------------|
    |                               |
    | 7. POST-as-GET fetch cert     |
    |------------------------------>|
    |                               |
    | 8. Return full certificate    |
    |<------------------------------|

A.2. Signature Certificate Order Flow (Using pk-01 Challenge)

Client                                      ACME Server
    |                                               |
    | 1. newOrder                                   |
    | (identifiers, popKey=signature public key)    |
    |---------------------------------------------->|
    |                                               |
    | 2. Return Order + pk-01 challenge             |
    |<----------------------------------------------|
    |                                               |
    | 3. Complete pk-01 challenge                   |
    | (sign with signature private key)             |
    |---------------------------------------------->|
    Note: Server verification successful
    |                                               |
    | 4. finalize ({})                              |
    |---------------------------------------------->|
    Note: Server issues signature certificate
    |                                               |
    | 5. Return certificate URL                     |
    |<----------------------------------------------|
    |                                               |
    | 6. POST-as-GET to retrieve certificate        |
    |---------------------------------------------->|
    |                                               |
    | 7. Return signature certificate content       |
    |<----------------------------------------------|

A.3. Encryption Certificate Order Flow (Using auth-01 Challenge)

Client                                      ACME Server                                  KMC
    |                                              |                                        |
    | 1. newOrder                                  |                                        |
    | (identifiers, authKey=signature JWK, optional includeEnvelope)                        |
    |--------------------------------------------->|                                        |
    |                                              |                                        |
    | 2. Return Order + id auth + auth-01 auth obj |                                        |
    |<---------------------------------------------|                                        |
    |                                              |                                        |
    | 3. Complete HTTP-01 / DNS-01 identifier challenges                                    |
    |--------------------------------------------->|                                        |
    |                                              |                                        |
    | 4. Complete auth-01 challenge                |                                        |
    | Input tuple: URL + token + account pubkey fp |                                        |
    |--------------------------------------------->|                                        |
    Note over ACME Server:
    5. Signature & r/s range check passed, identity auth complete
    |                                              |                                        |
    | 6. finalize ({})                             |                                        |
    |--------------------------------------------->|                                        |
    Note over ACME Server:
    7. Validate authKey signature certificate exists & valid
    |                                              |--------------------------------------->|
    |                                              | 8. Trigger KMC, send signature public key|
    |                                              |                                        |
    Note over KMC:
    9. Generate key pair, escrow private key, build signedAndEnvelopedData
    |                                              |<---------------------------------------|
    |                                              | 10. Return encryption cert + envelope
    |<---------------------------------------------|                                        |
    | 11. finalize response (cert URL + optional envelope), Cache-Control: no-store, private |
    |                                              |                                        |
    | 12. POST-as-GET fetch encryption certificate |                                        |
    |--------------------------------------------->|                                        |
    |                                              |                                        |
    | 13. Return encryption cert (sm2AuthKeyHash ext)|                                      |
    |<---------------------------------------------|                                        |
    Note over Client:
    14. If envelope exists: decrypt with signature private key to get encryption private key

A.4. Complete HTTP Interaction Example (Normal Flow)

The following example shows the complete HTTP interaction for requesting an encryption certificate using the auth-01 challenge.¶

Step 1: Create Order (newOrder)¶

POST /acme/new-order HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
    "protected": "...",
    "payload": "eyJpZGVudGlmaWVycyI6W3sidHlwZSI6ImRucyIsInZhbHVlIjoiZXhhbXBsZS5jb20ifV0sImF1dGh LZXkiOnsia3R5IjoiRUMiLCJjcnYiOiJzbTJwMjU2djEiLCJ4IjoiLi4uIiwieSI6Ii4uLiJ9LCJpbmNsdW RlRW52ZWxvcGUiOnRydWV9",
    "signature": "..."
}

The decoded payload is:¶

{
    "identifiers": [{"type": "dns", "value": "example.com"}],
    "authKey": {
        "kty": "EC",
        "crv": "sm2p256v1",
        "x": "...",
        "y": "..."
    },
    "includeEnvelope": true
}

Step 2: Server Returns Order and Challenges¶

HTTP/1.1 201 Created
Content-Type: application/json
Location: https://example.com/acme/order/123
{
    "status": "pending",
    "expires": "2026-08-15T00:00:00Z",
    "identifiers": [{"type": "dns", "value": "example.com"}],
    "authorizations": [
        "https://example.com/acme/authz/456",
        "https://example.com/acme/authz/789"
    ],
    "finalize": "https://example.com/acme/order/123/finalize"
}

Step 3: Retrieve Authorization and Complete auth-01 Challenge¶

In this example, authz/456 is the identifier authorization object, and authz/789 is the auth-01 dedicated authorization object. Retrieve via POST-as-GET:¶

POST /acme/authz/789 HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
    "protected": "...",
    "payload": "",
    "signature": "..."
}

HTTP/1.1 200 OK
Content-Type: application/json
{
    "status": "pending",
    "identifier": {"type": "dns", "value": "example.com"},
    "challenges": [
        {
            "type": "auth-01",
            "url": "https://example.com/acme/chall/102",
            "token": "M4jVv6ZqXrEuTkAyC1wNs9BhPdGoLfR2",
            "status": "pending"
        }
    ]
}

The client completes the auth-01 challenge:¶

1. Using the account public key that authenticated the newOrder request for this Order, compute its JWK Thumbprint according to RFC 7638 to obtain account_thumbprint.¶

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. Sign the hash using the signature private key with SM2, producing an ASN.1 DER-encoded SEQUENCE { r, s }.¶

5. Base64url-encode the signature value.¶

POST /acme/chall/102 HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
    "protected": "...",
    "payload": "eyJ0eXBlIjoiYXV0aC0wMSIsImF1dGhTaWduYXR1cmUiOiJiYXNlNjR1cmwoQVNOLjEgREVSIFN FUVVFTkNFIHsgciwgcyB9KSJ9",
    "signature": "..."
}

The decoded payload is:¶

{
    "type": "auth-01",
    "authSignature": "base64url(ASN.1 DER SEQUENCE { r, s })"
}

Step 4: Submit finalize Request and Retrieve Envelope¶

POST /acme/order/123/finalize HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
    "protected": "...",
    "payload": "e30",
    "signature": "..."
}

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store, private
{
    "status": "valid",
    "expires": "2026-08-15T00:00:00Z",
    "identifiers": [{"type": "dns", "value": "example.com"}],
    "authorizations": ["https://example.com/acme/authz/456", "https://example.com/acme/authz/789"],
    "finalize": "https://example.com/acme/order/123/finalize",
    "certificate": "https://example.com/acme/cert/321",
    "envelope": "base64url(ASN.1 DER of GM/T 0010 signedAndEnvelopedData)"
}

Step 5: Retrieve Encryption Certificate¶

POST /acme/cert/321 HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
    "protected": "...",
    "payload": "",
    "signature": "..."
}

HTTP/1.1 200 OK
Content-Type: application/pem-certificate-chain
-----BEGIN CERTIFICATE-----
... (encryption certificate, containing sm2AuthKeyHash extension)
-----END CERTIFICATE-----

A.5. Error Scenario HTTP Interaction Examples

Error Scenario 1: KMC Unavailable¶

POST /acme/order/123/finalize HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
    "protected": "...",
    "payload": "e30",
    "signature": "..."
}

HTTP/1.1 503 Service Unavailable
Content-Type: application/problem+json
{
    "type": "urn:ietf:params:acme:error:kmcUnavailable",
    "detail": "The Key Management Center is temporarily unavailable. Please retry later.",
    "status": 503
}

Error Scenario 2: finalize Request for Encryption Certificate Order Contains CSR¶

POST /acme/order/123/finalize HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
    "protected": "...",
    "payload": "eyJjc3IiOiJiYXNlNjR1cmwoUEtDUzEwIENTUikifQ",
    "signature": "..."
}

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
{
    "type": "urn:ietf:params:acme:error:invalidCSR",
    "detail": "The finalize request for an encryption certificate order must use an empty payload; the key pair is generated by the KMC.",
    "status": 400
}

Error Scenario 3: SM2 Signature r or s Out of Range¶

POST /acme/chall/102 HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
    "protected": "...",
    "payload": "eyJ0eXBlIjoiYXV0aC0wMSIsImF1dGhTaWduYXR1cmUiOiIuLi4ifQ",
    "signature": "..."
}

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
{
    "type": "urn:ietf:params:acme:error:invalidSM2Signature",
    "detail": "Invalid SM2 signature parameters: r or s out of range [1, n-1]",
    "status": 400
}

A.6. Error Handling Flow

                            +---------------------------+
                            | A: newOrder for encryption |
                            +-------------+-------------+
                                          |
                                          v
                  +---------------------------------------------+
                  | B: Check if authKey exists in request payload |
                  +------------------+--------------------------+
                                     |
         +---------------------------+---------------------------+
         |No                                                      |Yes
         v                                                        v
+------------------------+                +------------------------------------------------+
| C: Return 400 authKey |                | F: Create identifier auth objects +            |
| authKeyMissing Error  |                |    dedicated auth-01 authorization object     |
+------------------------+                +----------------+---------------------------------+
                                                          |
                                                          v
                                +------------------------------------------------+
                                | G: Are all authorization objects fully valid?  |
                                +------------------+-------------------------------+
                                                  |
                        +-------------------------+--------------------------+
                        |Failure                                              |Success
                        v                                                    v
+------------------------------------------------+       +-------------------------------------------------+
| H: Return error response                       |       | V: Verify authKey’s signature certificate |
| Note: Completed auth-01 in same Order          |       |    exists and is valid (default enabled)  |
|       does not need re-run; cannot reuse       |       +----------------+--------------------------+
|       auth data across separate Orders         |                        |
+------------------------------------------------+         +-------------+----------------+
                                                          |No             |Yes
                                                          v                v
                                               +----------------+  +--------------------------+
                                               | W: 403         |  | I: Trigger KMC subsystem  |
                                               | signingCertReq |  |    pass signature pubkey  |
                                               +----------------+  +-----------+------------+
                                                                               |
                                                                               v
                                                                    +----------------+
                                                                    | J: KMC operation|
                                                                    +------+---------+
                                                                           |
                                                         +----------------+----------------+
                                                         |Failure                         |Success
                                                         v                                v
                                        +--------------------------------+    +------------------------+
                                        | K: 503 kmcUnavailable /          |    | L: Check includeEnvelope flag |
                                        |    500 envelopeGenerationFailed  |    +-----------+------------+
                                        +--------------------------------+                |
                                                                          +---------+---------+
                                                                                    |true     |false/unset
                                                                                    v         v
                                                              +------------------------+  +------------------------+
                                                              | M: finalize response |  | N: finalize response  |
                                                              | Return cert URL +    |  | Return cert URL only  |
                                                              | envelope             |  | Cache-Control:        |
                                                              | Cache-Control:       |  | no-store, private     |
                                                              | no-store, private    |  +------------------------+
                                                              +------------------------+

B.1. Client Signature Construction Steps

When completing the auth-01 challenge, the client MUST follow these steps:¶

1. Using the account public key that authenticated the newOrder request for this Order, compute its JWK Thumbprint according to [RFC7638] to obtain account_thumbprint.¶

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. Sign the hash using the signature private key with SM2, outputting an ASN.1 DER-encoded SEQUENCE { r INTEGER, s INTEGER }.¶

5. Ensure the signature uses the normalized form s <= n/2; if s > n/2, replace it with n - s.¶

6. Base64url-encode the DER-encoded signature value and place it in the authSignature field.¶

Signature Construction Order Warning: The client MUST strictly use the field order specified above. Any deviation will cause server verification to fail.¶

For SM2 signature encoding considerations, see Section 2's SM3 OID note. The client should use an ASN.1 DER encoding library and be aware of the 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 prepended.¶

Provisioning authKey: The client need only provide the JWK-formatted authKey in the JWS Payload of the newOrder request; the SubjectPublicKeyInfo encoding is performed by the server.¶

Retrieving the envelope from the finalize response: If includeEnvelope: true was explicitly set but the envelope field is not received, it SHOULD be treated as an error and the flow terminated. When not explicitly set, the client SHOULD NOT expect the envelope field.¶

B.2. Server Verification Steps

When verifying the auth-01 signature, the server MUST use exactly the same construction method as the client. The specific steps are:¶

1. Obtain kid from the JWS header, look up the corresponding account public key, verify the JWS signature, and confirm that the account is the account that created the Order.¶

2. Obtain the account JWK from the account state stored when the Order was created and compute account_thumbprint according to RFC 7638; do not extract this value from authSignature or the challenge response.¶

3. Extract the signature value from authSignature, verify that the token matches the challenge object and has not been used.¶

4. Using the account_thumbprint computed in Step 2, construct the signature input message = "ACME auth-01" || 0x00 || challenge_url || 0x00 || token_utf8_bytes || 0x00 || account_thumbprint.¶

5. Compute hash = SM3(message) and verify the signature using the public key from authKey.¶

6. Verify that both r and s are in the range [1, n-1] and that s <= n/2.¶

7. Verify that the signing public key matches the authKey declared in the newOrder request.¶

8. Verify that the account identified by kid matches the account corresponding to authKey.¶

If the account key was changed before challenge completion, the server MUST reject the challenge response, transition the affected incomplete auth-01 authorization object and its Order 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 envelope field, the server MUST set the Cache-Control: no-store, private header and ensure that the finalize endpoint is explicitly disabled for caching at the CDN level.¶

Audit Logs: The server SHOULD log all encryption certificate request operations, including auth-01 challenge completion, KMC invocation results, certificate issuance records, and envelope delivery records.¶

B.3. Relying Party Verification Flow

When validating an encryption certificate, relying parties MUST check the sm2AuthKeyHash extension:¶

1. Extract the sm2AuthKeyHash extension value (if present) from the encryption certificate and parse the SM2AuthKeyHash structure.¶

2. If the extension is absent, the certificate does not conform to this specification (it is a mandatory extension); the relying party MAY treat it as a foreign or legacy certificate per its policy but SHOULD log the absence in the audit log.¶

3. If the extension is present, verify that hashAlgorithm.algorithm is the standard SM3 OID (1.2.156.10197.1.401). If unrecognized, the relying party SHOULD reject the certificate.¶

4. Extract the 32-byte hash value from the hashValue field.¶

5. Extract the public key from the expected signature certificate and compute its SM3 hash.¶

6. Compare the two values. If they do not match, the authorization binding of the encryption certificate is invalid, and the relying party MUST reject the certificate and treat it as a security violation.¶

B.4. KMC Core Guidance

1. The random number generator used for key generation MUST comply with [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 as specified in [GMT.0003.4-2012] Section 4.2.¶

3. When parsing the SubjectPublicKeyInfo structure passed by the server, implementations MUST comply with [RFC5480] encoding specifications and MUST NOT support direct identification using the SM2 algorithm OID.¶

4. After an encryption certificate is revoked or expires, the escrowed private key SHOULD be deleted within a reasonable timeframe; the deletion period SHOULD be clearly stated in the CP/CPS (30 days is RECOMMENDED), and the deletion operation SHOULD be logged.¶

5. For deployments with higher requirements regarding single point of 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.¶