ACME Extension for SM2 Dual-Certificate System
draft-geng-acme-sm2dualcert-extension-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-extension-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 Extension for SM2 Dual-Certificate System
draft-geng-acme-sm2dualcert-extension-00
Abstract
This document describes the extension of the ACME protocol [RFC8555]
to support automated issuance of SM2 dual certificates (signature
certificates and encryption certificates) in the Chinese National
Cryptography certificate system. This document does not represent
IETF consensus; the technical solution is applicable only to PKI
environments based on an SM2 dual-certificate system.
Under the framework of the ACME protocol [RFC8555], this document
proposes using two separate Orders to request the two certificates.
For the signature certificate, the existing ACME workflow is reused,
optionally using the standard CSR approach or the pk-01 challenge
[I-D.geng-acme-public-key]. For the encryption certificate, this
document defines a new challenge type, auth-01, specifically for
*identity authorization* scenarios: the client proves possession of
the *signature private key* to authorize the Key Management Center
(KMC) to generate an encryption key pair and issue the encryption
certificate on behalf of the entity. This challenge type
intrinsically binds the issuance of the encryption certificate to the
signature key, requiring no additional binding identifiers.
All extensions are compatible with the existing ACME resource model.
No new Order types are introduced. This document only adds optional
fields in the client's newOrder request (authKey, includeEnvelope)
and an additional field in the server's response (envelope), without
changing the core semantics or state machine of Order.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Geng, et al. Expires 21 January 2027 [Page 1]
Internet-Draft ACME auth Challenge July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. About the Nature of This Document . . . . . . . . . . . . 4
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
1.5. Solution Overview . . . . . . . . . . . . . . . . . . . . 6
1.6. Scope and Positioning . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. SM2 Dual-Certificate Workflow . . . . . . . . . . . . . . . . 8
3.1. Creating Two Separate Orders . . . . . . . . . . . . . . 9
3.2. Signature Certificate Request Flow . . . . . . . . . . . 9
3.3. Encryption Certificate Request Flow . . . . . . . . . . . 10
3.3.1. Digital Envelope Format Specification . . . . . . . . 10
3.3.2. auth-01 Challenge Details . . . . . . . . . . . . . . 12
3.3.3. Certificate Issuance Requirements . . . . . . . . . . 20
4. Extension Specifications . . . . . . . . . . . . . . . . . . 22
4.1. SubjectPublicKeyInfo Encoding of the Signature Public Key
(Server-to-KMC Interface) . . . . . . . . . . . . . . . . 22
4.2. sm2AuthKeyHash Extension . . . . . . . . . . . . . . . . 23
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
Geng, et al. Expires 21 January 2027 [Page 2]
Internet-Draft ACME auth Challenge July 2026
5.1. New ACME Challenge Type . . . . . . . . . . . . . . . . . 24
5.2. New ACME Error Types . . . . . . . . . . . . . . . . . . 25
5.3. Certificate Extension OID Assignment (Non-IANA Matter) . 27
5.4. Transition Period and OID Migration . . . . . . . . . . . 27
5.5. JOSE Registration . . . . . . . . . . . . . . . . . . . . 28
5.6. ACME Order Object Field Registration . . . . . . . . . . 28
6. Security and Operational Considerations . . . . . . . . . . . 28
6.1. KMC Infrastructure Security . . . . . . . . . . . . . . . 29
6.2. Key Usage Separation . . . . . . . . . . . . . . . . . . 29
6.3. Challenge Signature Security . . . . . . . . . . . . . . 30
6.4. Digital Envelope and Data Protection . . . . . . . . . . 30
6.5. Intrinsic Binding and Relying Party Verification . . . . 31
6.6. KMC Compliance and Certificate Revocation . . . . . . . . 31
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 32
7.1. Dual-Order Model vs. Single-Order Model . . . . . . . . . 32
7.2. Authorization Object Reuse vs. New Order-Level Field . . 33
7.3. Identity Authorization vs. Identifier Authorization . . . 34
7.4. Envelope Delivery and Explicit Opt-In . . . . . . . . . . 34
7.5. Auditability of Key Escrow . . . . . . . . . . . . . . . 34
8. Future Considerations . . . . . . . . . . . . . . . . . . . . 35
8.1. General Model as a "Key Escrow Certificate Profile" . . . 35
8.2. Synergy with the ACME Extension Ecosystem . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.1. Normative References . . . . . . . . . . . . . . . . . . 36
9.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Protocol Interaction Diagrams . . . . . . . . . . . 38
A.1. Signature Certificate Order Flow (Standard CSR
Approach) . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2. Signature Certificate Order Flow (Using pk-01
Challenge) . . . . . . . . . . . . . . . . . . . . . . . 39
A.3. Encryption Certificate Order Flow (Using auth-01
Challenge) . . . . . . . . . . . . . . . . . . . . . . . 40
A.4. Complete HTTP Interaction Example (Normal Flow) . . . . . 41
A.5. Error Scenario HTTP Interaction Examples . . . . . . . . 45
A.6. Error Handling Flow . . . . . . . . . . . . . . . . . . . 46
Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 47
B.1. Client Signature Construction Steps . . . . . . . . . . . 48
B.2. Server Verification Steps . . . . . . . . . . . . . . . . 49
B.3. Relying Party Verification Flow . . . . . . . . . . . . . 50
B.4. KMC Core Guidance . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction
Geng, et al. Expires 21 January 2027 [Page 3]
Internet-Draft ACME auth Challenge July 2026
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.
Geng, et al. Expires 21 January 2027 [Page 4]
Internet-Draft ACME auth Challenge 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.
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.
Geng, et al. Expires 21 January 2027 [Page 5]
Internet-Draft ACME auth Challenge July 2026
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.
Geng, et al. Expires 21 January 2027 [Page 6]
Internet-Draft ACME auth Challenge July 2026
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.
2. Terminology
The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*",
"*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*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, as shown here.
This document uses the following terms:
* *Signature certificate*: A public key certificate used for
identity authentication and digital signatures.
* *Encryption certificate*: A public key certificate used for data
encryption and key agreement.
* *Digital envelope*: A cryptographic structure as defined in
[GMT.0010-2023], using either the signedAndEnvelopedData or
envelopedData data type. Use of signedAndEnvelopedData is
*RECOMMENDED* as it provides both confidentiality and integrity
protection.
* *Key Management Center (KMC)*: A trusted entity as defined in
[GMT.0034-2014] that generates and escrows encryption private
keys. In the context of this document, the KMC is considered a
trusted subsystem of the CA, and its operations *MUST* be subject
to the CA's overall audit and compliance framework.
Geng, et al. Expires 21 January 2027 [Page 7]
Internet-Draft ACME auth Challenge July 2026
* *Key Escrow*: A mechanism by which encryption private keys are
centrally generated and held by a trusted third party (the KMC).
The key escrow described in this document is a mandatory
requirement of [GMT.0034-2014] and related regulatory frameworks.
* *Identity Authorization*: A mechanism by which possession of an
identity key (signature private key) is proven to authorize
specific operations (such as requesting an encryption
certificate).
* *authKey*: The *signature public key* (in JWK format) declared by
the client in the JWS Payload of the newOrder request, used for
identity authorization in the auth-01 challenge. This field is
semantically distinct from the popKey field (defined in
[I-D.geng-acme-public-key] for the pk-01 challenge): authKey is
for "proving identity to authorize issuance of an encryption
certificate," whereas popKey is for "proving possession of the
final certificate public key" (see Section 3.2 and Section 3.3.2).
* *account_thumbprint*: The *JWK Thumbprint* of the ACME account
public key that authenticated the encryption-certificate newOrder
request when the server accepted it, computed according to
[RFC7638] Section 3. The server *MUST* store this value as part
of the Order state. It is not transmitted in the challenge
response; instead, the client and server compute it independently
from the same account public key and include it in the auth-01
signature input to provide cryptographic account binding.
*Note on OIDs*: All cryptographic algorithm OIDs used in this
document are defined in [GMT.0006-2023]. The permanent OID for the
custom certificate extension (id-sm2-auth-key-hash) defined in this
document is to be assigned by the China Cryptography Industry
Standardization Technical Committee (CCSTC) under its managed
1.2.156.10197 arc (which is not within IANA's management scope; see
Section 5.3). During the experimental phase, a temporary OID under
the enterprise arc (1.3.6.1.4.1.2011.2.467) is used.
*SM3 OID Note*: The standard OID for the SM3 cryptographic hash
algorithm used in this specification is 1.2.156.10197.1.401 (id-hash-
sm3), defined in [GMT.0006-2023] under the CCSTC 1.2.156.10197 arc.
All certificates and signatures *MUST* use this OID, consistent with
all existing GM implementations (OpenSSL, GmSSL, etc.).
3. SM2 Dual-Certificate Workflow
Geng, et al. Expires 21 January 2027 [Page 8]
Internet-Draft ACME auth Challenge July 2026
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).
Geng, et al. Expires 21 January 2027 [Page 9]
Internet-Draft ACME auth Challenge July 2026
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.
3.3.1. Digital Envelope Format Specification
The digital envelope *SHOULD* comply with the following
specifications:
Geng, et al. Expires 21 January 2027 [Page 10]
Internet-Draft ACME auth Challenge July 2026
*Data Type*: It is *RECOMMENDED* to use the signedAndEnvelopedData
type defined in Section 10 of [GMT.0010-2023], which provides both
confidentiality and integrity protection. When
signedAndEnvelopedData is used, the client *MUST* verify the
signature *before* decrypting the envelope to ensure it has not been
tampered with during transmission.
If the deployment environment already protects communication between
the ACME server and the client via secure channels such as TLS, and
the communication channel provides sufficient integrity protection,
the KMC *MAY* use the envelopedData type (defined in Section 9 of
[GMT.0010-2023]) to reduce signature operation overhead. When
envelopedData is used, the client *SHOULD* ensure that the
communication channel with the server provides sufficient integrity
protection. Regardless of the type chosen, the confidentiality
protection of the digital envelope is achieved through SM4 symmetric
encryption and SM2 asymmetric encryption.
*Version*: When using KeyTransRecipientInfo, the version field
*SHOULD* be 0.When using other recipient info types, the version
value *SHOULD* be set according to Section 7 of [GMT.0010-2023].
*RecipientInfo*: The KeyTransRecipientInfo type *SHOULD* be used.
The keyEncryptionAlgorithm field *SHOULD* use OID
1.2.156.10197.1.301.3 (SM2 public-key encryption algorithm, defined
in [GMT.0006-2023]). This OID implicitly uses the Key Derivation
Function (KDF) specified in Section 4 of [GMT.0003.4-2012]; the KDF
output length matches the SM4 key length (128 bits), with specific
parameters as specified in Section 4.2 of [GMT.0003.4-2012].
Implementers need not specify a separate KDF OID.
*EncryptedContentInfo*:
* The contentEncryptionAlgorithm field *SHOULD* use the SM4-CBC
algorithm OID defined in [GMT.0006-2023].
* The encryptedContent *SHOULD* contain the encryption private key
encrypted with an SM4 symmetric key. The SM4 symmetric key *MUST*
be a 128-bit (16-byte) key as specified in [GMT.0002-2012]. The
SM4 symmetric key *MUST* be generated using a hardware random
number generator compliant with [GMT.0078-2020], or an equivalent
security standard; its output *SHOULD* pass the randomness tests
specified in [GMT.0005-2021], and it is *RECOMMENDED* to combine
it with system-level entropy sources to ensure cryptographic
security of the key entropy even in the event of hardware RNG
anomalies.
Geng, et al. Expires 21 January 2027 [Page 11]
Internet-Draft ACME auth Challenge July 2026
*Encoding*: The complete digital envelope structure *SHOULD* be
encoded using ASN.1 DER (Distinguished Encoding Rules).
*Transfer Encoding*: When transmitted in JSON messages (e.g., in the
finalize response), the DER-encoded digital envelope *SHOULD* be
base64url-encoded without padding as defined in [RFC4648] Section 5.
The digital envelope *SHOULD* contain:
* The encryption private key encrypted with an SM4 symmetric key
(128 bits).
* The SM4 symmetric key encrypted with SM2 (using the client's
signature public key).
Upon receiving the response, the client SHOULD decrypt the digital
envelope using its signature private key to obtain the plaintext
encryption private key.
*Note on Private Key Usage*: The client's signature private key is
*only* used to decrypt the digital envelope to obtain the encryption
private key. All subsequent cryptographic operations involving data
encryption or decryption *SHOULD* use the encryption private key.
The signature private key *MUST NOT* be used for any data encryption
or decryption operations beyond opening the digital envelope, in
compliance with the key usage separation principle specified in
[GMT.0034-2014].
KMC signature certificate trust anchor configuration, lifecycle
management, and communication security requirements between the ACME
server and the KMC are described in Section 6.
3.3.2. auth-01 Challenge Details
The auth-01 challenge is a new ACME challenge type whose core
semantics are *identity authorization*: the client proves possession
of the *signature private key* to authorize the server to generate an
encryption certificate on its behalf.
*Challenge-Authorization Relationship*:
The ACME authorization model comprises two orthogonal dimensions:
identifier authorization (proving that the client controls the
identifier) and identity authorization (proving that the client
possesses a specific identity key). The SM2 dual-certificate system
requires that the signature certificate and the encryption
certificate belong to the same entity. By placing auth-01 and
identifier authorization challenges in different authorization
Geng, et al. Expires 21 January 2027 [Page 12]
Internet-Draft ACME auth Challenge July 2026
objects within the same Order, this design ensures that the two types
of authorization are independent but both must be completed. The
conditions under which an Order enters the ready state follow
[RFC8555] Section 7.1.6, i.e., all authorization objects referenced
by the Order are valid.
For an encryption certificate Order, the server *MUST* place the
auth-01 challenge in a *dedicated authorization object* that *MUST
NOT* contain any other types of challenges; each identifier still has
its own separate authorization object containing regular identifier
authorization challenges (e.g., HTTP-01, DNS-01) as specified in
[RFC8555] Section 7.1.4. This design does not modify the RFC 8555
authorization state machine. By placing auth-01 in a dedicated
authorization object, this design equivalently achieves the
requirement that "both identifier authorization and identity
authorization must be completed" without modifying the RFC 8555
authorization state machine.
Regardless of how many identifiers the Order contains, the server
*MUST* create *exactly one* auth-01 dedicated authorization object
for each encryption certificate Order. The identifier field of this
dedicated authorization object *MUST* copy the first element of the
Order object's identifiers array returned by the server; the client
*MUST* select its processing logic based on the challenge object's
type field (rather than the authorization object's identifier).
*Authorization Object State and Reuse Rules*:
* The state of the auth-01 dedicated authorization object and the
identifier authorization objects are independent; the two types of
challenges may be completed in parallel.
* If any authorization object transitions to invalid, the Order
correspondingly transitions to invalid.
* *The auth-01 dedicated authorization object does not constitute
identifier authorization*: the server *MUST NOT* count it as
authorization for the identifier indicated by its identifier
field—it *MUST NOT* be reused for any Order under the
authorization reuse mechanisms of [RFC8555] Section 7.1.3/
Section 7.4, nor *MUST* it be counted in certificate revocation
authorization determinations under [RFC8555] Section 7.6.
* When creating an encryption certificate Order, the server *MUST
NOT* associate any pre-existing auth-01 authorization object; it
*MUST* create a new auth-01 authorization object and challenge
instance (new URL, new token) for each Order.
Geng, et al. Expires 21 January 2027 [Page 13]
Internet-Draft ACME auth Challenge July 2026
* Within the same Order and within the authorization object's
validity period (expires), the client need only retry failed
identifier challenges; a successfully completed auth-01
authorization object need not be retried; after the authorization
object expires, the client *MUST* restart the Order.
*Handling Orders with Empty Identifiers*: If an Order's identifiers
array is empty, the server *SHOULD* reject the Order and return a
urn:ietf:params:acme:error:malformed error.
The token for the auth-01 challenge is independently and randomly
generated by the server, unrelated to the token of challenges in
other authorization objects within the same Order. The token *MUST*
be generated by a cryptographically secure random number generator
with at least 128 bits of entropy; the challenge object's url *MUST*
be unique across the server's entire lifecycle and *MUST NOT* be
reused.
{
"type": "auth-01",
"url": "https://example.com/acme/chall/123",
"token": "q9K3xwLmZ2VtT7cPnE8fRaYb01UgHdSJ",
"status": "pending"
}
*Client Response*:
The client signs the challenge information using its *signature
private key*. The signature algorithm is *sm2-with-SM3* (OID
1.2.156.10197.1.501, defined in [GMT.0006-2023]), i.e., the challenge
information is hashed using the SM3 hash algorithm (OID
1.2.156.10197.1.401), and then the hash value is signed using the SM2
signature algorithm (OID 1.2.156.10197.1.301) with the sm2p256v1
curve parameters defined in [GMT.0003.5-2012].
*Note*: sm2-with-SM3 (OID 1.2.156.10197.1.501) identifies the
combination of the SM2 signature algorithm and the SM3 hash
algorithm, used to identify the complete signature algorithm. This
OID is distinct from the SM3 hash algorithm OID
(1.2.156.10197.1.401); the former identifies the complete signature
algorithm combination, while the latter identifies the hash algorithm
alone.
The challenge response uses the authSignature field defined in this
specification to carry the signature value:
Geng, et al. Expires 21 January 2027 [Page 14]
Internet-Draft ACME auth Challenge July 2026
{
"type": "auth-01",
"authSignature": "base64url(signature_bytes)"
}
where signature_bytes is the ASN.1 DER-encoded byte string of the SM2
signature generated using the signature private key over the
challenge information.
*Signature Algorithm Details*:
Detailed steps for signature construction and verification are
provided in Appendix B.1 and B.2. The core signature input is
constructed as follows:
message = "ACME auth-01" || 0x00 || challenge_url || 0x00 || token_utf8_bytes || 0x00 || account_thumbprint
where challenge_url is the url field value of the challenge object,
token is the token string provided in the challenge object, and
account_thumbprint is the JWK Thumbprint (RFC 7638) of the account
public key used when the server accepted the Order's newOrder
request. The account_thumbprint is not included in the challenge
response. The client computes it from the account public key used to
submit newOrder; the server obtains it from the account state stored
when the Order was created. The signature value is
SM2_sign(SM3(message)) and *MUST* use the normalized form (s <= n/2).
*Note*: JWK Thumbprint [RFC7638] uses the SHA-256 hash algorithm
as required by that specification. This is distinct from the SM3
hash used in the ShangMi (SM) cipher suites but does not affect
the overall consistency of the SM algorithm system.
*Server Verification*:
The ACME server verifies the following:
1. Verifies the JWS signature and confirms that the account
identified by the JWS kid is the account that created the Order.
2. *Reconstructs account_thumbprint*: Obtains the account JWK from
the account state stored when the Order was created and computes
its JWK Thumbprint according to [RFC7638]. The server *MUST NOT*
attempt to extract account_thumbprint from authSignature or the
challenge response.
3. Verifies that the token matches the token in the challenge object
and has not been used.
Geng, et al. Expires 21 January 2027 [Page 15]
Internet-Draft ACME auth Challenge July 2026
4. Reconstructs the complete signature input using the stored
account_thumbprint, challenge URL, and token, computes
SM3(message), and verifies the signature using the public key
from authKey.
5. Verifies that both r and s are in the range [1, n-1] and that s
<= n/2.
6. Verifies that the signing public key matches the authKey declared
in the newOrder request.
7. Verifies that the account identified by the kid in the JWS header
matches the account corresponding to authKey (defense in depth).
*Account Key Rollover*: If the client changes its account key under
[RFC8555] Section 7.3.5 before completing the auth-01 challenge, the
server *MUST* transition the incomplete auth-01 authorization object
and its Order bound to the old account_thumbprint to invalid. The
client *MUST* create a new Order using the new account key. The
server *MUST NOT* replace the account_thumbprint stored in an
existing Order with the thumbprint of the new account key.
*Provisioning Rules for authKey*:
* The client *MUST* provide the authKey field in the JWS Payload of
the newOrder request for the encryption certificate; if missing,
the server *MUST* reject the request and return a
urn:ietf:params:acme:error:authKeyMissing error.
* Before triggering the KMC, the server *MUST* deterministically
convert authKey to a SubjectPublicKeyInfo structure as specified
in Section 4.1 and pass it to the KMC; the client need not submit
the ASN.1 encoding of the same public key redundantly.
*Client Public Key Declaration*:
The client declares its signature public key via the authKey field in
the JWS Payload of the newOrder request. authKey *MUST* be
represented in JSON Web Key (JWK) format [RFC7517], with the
following specific requirements:
* kty *MUST* be "EC".
* crv *MUST* be "sm2p256v1" (lowercase; curve parameters are defined
in [GMT.0003.5-2012], and this name follows the naming convention
used by widely deployed implementations such as GmSSL/OpenSSL).
Geng, et al. Expires 21 January 2027 [Page 16]
Internet-Draft ACME auth Challenge July 2026
* x and y *MUST* be base64url-encoded elliptic curve point
coordinates (32 bytes each).
"sm2p256v1" is not currently in the IANA "JSON Web Key Elliptic
Curve" registry; this document requests its registration in
Section 5.5. Until registration is complete, JOSE libraries that
strictly validate crv values may reject this JWK; implementers
*SHOULD* relax validation as specified in this specification. The
JWS alg registration required for ACME account keys using the SM2
algorithm is outside the scope of this document and is to be
addressed by companion documents.
*KMC Trigger and Signature Certificate Verification*:
When processing the finalize request for this Order, before
triggering the KMC, the server *SHOULD* verify that the signature
certificate corresponding to authKey (i.e., the certificate whose
subject public key equals authKey) has been issued by this CA to the
same ACME account, has identifiers consistent with this Order, and is
in a valid state (not expired, not revoked). If verification fails,
the finalize request *SHOULD* fail and return a
urn:ietf:params:acme:error:signingCertRequired error (HTTP 403), and
the Order *SHOULD* transition to invalid. Since the four-element
signature already provides cryptographic account binding, this check
serves as a defense-in-depth measure. Deployments that choose to
disable this check *SHOULD* document the rationale and ensure that
alternative mitigations are in place.
Upon successful verification, the server *MUST* pass the signature
public key from authKey to the KMC, which generates the encryption
key pair and escrows the encryption private key; the KMC *MUST*
assemble the digital envelope *only* when the client explicitly sets
includeEnvelope: true.
*Complete Flow*:
1) *Order Creation*: The client creates an encryption certificate
Order, including the authKey field and the optional includeEnvelope
field (default false) in the JWS Payload of the newOrder request.
Extension fields are passed by directly adding them to the JSON
object in the newOrder request; if the deployment environment
supports [I-D.ietf-acme-profiles], they may also be passed via its
Order metadata extension mechanism.
Payload example:
Geng, et al. Expires 21 January 2027 [Page 17]
Internet-Draft ACME auth Challenge July 2026
{
"identifiers": [{"type": "dns", "value": "example.com"}],
"authKey": {
"kty": "EC",
"crv": "sm2p256v1",
"x": "...",
"y": "..."
},
"includeEnvelope": true
}
2) *Authorization and Challenges*: The server returns identifier
authorization objects and one auth-01 dedicated authorization object.
The client completes all required identifier authorization
challenges, then completes the auth-01 challenge using its signature
private key, with the authSignature field in the response containing
the ASN.1 DER-encoded signature value. The server verifies the
signature validity.
3) *Server Triggers KMC*: After all authorization objects are valid,
the Order enters the ready state. The client submits an empty
payload ({}) finalize request. The server performs the signature
certificate existence check (enabled by default) and triggers the KMC
to generate the encryption key pair. When includeEnvelope is false
or not set, the KMC *SHOULD* skip assembling and transmitting the
digital envelope.
4) *Order Completion*: The server issues the encryption certificate
and transitions the Order to valid. The server strictly follows the
includeEnvelope parameter in the finalize response: the envelope
field is returned *only* when explicitly set to true. If the server
uses asynchronous issuance (returning processing), the envelope field
is delivered in the POST-as-GET response to the Order URL after the
Order transitions to valid, with the same delivery rules. The server
*MUST* support client retrieval of the envelope throughout the
Order's retrievable lifecycle; this retrieval obligation applies
*only* to Orders with includeEnvelope: true. The client downloads
the encryption certificate via POST-as-GET from the certificate URL.
5) *Client Decryption*: If the response contains the envelope field,
the client decrypts the digital envelope using its signature private
key to obtain the plaintext encryption private key.
*Error Handling*:
The following error types are defined (using the
urn:ietf:params:acme:error: namespace):
Geng, et al. Expires 21 January 2027 [Page 18]
Internet-Draft ACME auth Challenge July 2026
+===================================================+======+=====================+
|Error Type |HTTP |Description |
| |Status| |
+===================================================+======+=====================+
|urn:ietf:params:acme:error:authKeyMissing |400 |authKey field missing|
| | |from JWS Payload of |
| | |newOrder request |
+---------------------------------------------------+------+---------------------+
|urn:ietf:params:acme:error:kmcUnavailable |503 |KMC temporarily |
| | |unavailable |
+---------------------------------------------------+------+---------------------+
|urn:ietf:params:acme:error:envelopeGenerationFailed|500 |KMC failed to |
| | |generate digital |
| | |envelope |
+---------------------------------------------------+------+---------------------+
|urn:ietf:params:acme:error:invalidCSR |400 |finalize request for |
| | |encryption |
| | |certificate Order |
| | |contains csr field |
+---------------------------------------------------+------+---------------------+
|urn:ietf:params:acme:error:invalidSM2Signature |400 |SM2 signature |
| | |verification failed |
| | |(r/s out of range or |
| | |invalid format). |
| | |Semantically distinct|
| | |from the standard |
| | |error type |
| | |badSignatureAlgorithm|
| | |(for unsupported JWS |
| | |signature algorithms)|
| | |defined in RFC 8555 |
| | |Section 6.7 |
+---------------------------------------------------+------+---------------------+
|urn:ietf:params:acme:error:signingCertRequired |403 |No valid signature |
| | |certificate found |
| | |corresponding to |
| | |authKey |
+---------------------------------------------------+------+---------------------+
|urn:ietf:params:acme:error:invalidKeyUsage |400 |KeyUsage in signature|
| | |certificate CSR does |
| | |not meet requirements|
+---------------------------------------------------+------+---------------------+
Table 1
*Design Note: The Nature of the auth-01 Authorization Object*
Geng, et al. Expires 21 January 2027 [Page 19]
Internet-Draft ACME auth Challenge July 2026
The auth-01 challenge is placed in a dedicated authorization object
that is separate from identifier authorization objects. This design
choice is motivated by the desire to reuse RFC 8555's existing
authorization and challenge infrastructure without introducing new
resource types.
This authorization object differs from standard RFC 8555
authorization objects in one respect: its identifier field serves as
a placeholder only; the auth-01 challenge does not validate control
over that identifier. This is achieved by server policy (the server
does not count this authorization object toward identifier
authorization reuse under RFC 8555 Section 7.1.3/Section 7.4, nor
toward certificate revocation authorization determinations under RFC
8555 Section 7.6), not by modifying the RFC 8555 authorization state
machine. The RFC 8555 state machine operates identically for this
authorization object; the server simply does not treat it as evidence
of identifier control.
The distinction between this dedicated authorization object and a
standard RFC 8555 authorization object is enforced by server policy,
not by a modification of the protocol's state machine semantics.
This pattern - using a dedicated authorization object for non-
identifier authorization - is intended as a reusable template for
future ACME extensions that require multiple independent
authorization factors within a single Order, such as device
attestation, post-quantum certificate migration, or other scenarios
where identity authorization is orthogonal to identifier
authorization.
3.3.3. Certificate Issuance Requirements
*Signature Certificate*:
* The KeyUsage extension *MUST* contain digitalSignature and/or
nonRepudiation. It *MUST NOT* contain keyEncipherment or
dataEncipherment.
* Other extensions follow the standard ACME workflow.
*Encryption Certificate*:
* The KeyUsage extension *MUST* contain keyEncipherment and/or
dataEncipherment, and *MAY* contain keyAgreement depending on the
deployment scenario (e.g., TLCP key exchange). It *MUST NOT*
contain digitalSignature or nonRepudiation.
Geng, et al. Expires 21 January 2027 [Page 20]
Internet-Draft ACME auth Challenge July 2026
* The certificate *MUST* contain the sm2AuthKeyHash extension
(defined in Section 4.2), which records the SM3 hash of the
signature public key that authorized this certificate.This
extension is marked as *non-critical* (critical = FALSE); relying
parties that do not understand this extension may still accept the
certificate but cannot verify the authorization binding.
* When issuing an encryption certificate, the CA *SHOULD* ensure
that the certificate has the same identifiers as the corresponding
signature certificate.
*Finalization Method (No CSR)*:
* The finalize request for an encryption certificate Order *MUST*
use an empty JSON object {} as the payload and *MUST NOT* contain
a csr field. When the server receives a request containing a csr
field, it *MUST* reject it and return a
urn:ietf:params:acme:error:invalidCSR error.
*KeyUsage Conflict Handling*:
* If the KeyUsage requested by the client in the *signature
certificate* CSR conflicts with the above requirements, the server
*MUST* reject the request and return a
urn:ietf:params:acme:error:invalidKeyUsage error. The encryption
certificate Order does not use a CSR; its KeyUsage is set directly
by the CA as specified in this section.
*finalize Response Format*:
Upon successfully processing the finalize request for an encryption
certificate Order, the server *SHOULD* return the following JSON
response. The envelope field is included *only* when the client
explicitly sets 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)"
}
The example above shows the response when the client sets
includeEnvelope: true; otherwise, the server omits the envelope
field.
Geng, et al. Expires 21 January 2027 [Page 21]
Internet-Draft ACME auth Challenge July 2026
The envelope field appears *only* in the finalize response for
encryption certificate Orders and in the POST-as-GET response to the
Order object after it transitions to valid. When returning a
response containing the envelope field, the server *MUST* set the
Cache-Control: no-store, private header.
4. Extension Specifications
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.
Geng, et al. Expires 21 January 2027 [Page 22]
Internet-Draft ACME auth Challenge July 2026
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.
Geng, et al. Expires 21 January 2027 [Page 23]
Internet-Draft ACME auth Challenge July 2026
*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. IANA Considerations
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):
+=========+==================================+======+===========+
| Label | Identifier Type | ACME | Reference |
+=========+==================================+======+===========+
| auth-01 | dns (reuses the first identifier | Y | RFC XXXX |
| | of the Order; this challenge | | |
| | does not validate identifier | | |
| | control; see Section 3.3.2) | | |
+---------+----------------------------------+------+-----------+
Table 2
*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.
Geng, et al. Expires 21 January 2027 [Page 24]
Internet-Draft ACME auth Challenge July 2026
5.2. New ACME Error Types
IANA is requested to register the following new error types in the
"ACME Error Types" registry:
Geng, et al. Expires 21 January 2027 [Page 25]
Internet-Draft ACME auth Challenge July 2026
+===================================================+=====================+=========+
|Error Type |Description |Reference|
+===================================================+=====================+=========+
|urn:ietf:params:acme:error:authKeyMissing |authKey field missing|RFC XXXX |
| |from JWS Payload of | |
| |newOrder request | |
+---------------------------------------------------+---------------------+---------+
|urn:ietf:params:acme:error:kmcUnavailable |KMC temporarily |RFC XXXX |
| |unavailable | |
+---------------------------------------------------+---------------------+---------+
|urn:ietf:params:acme:error:envelopeGenerationFailed|KMC failed to |RFC XXXX |
| |generate digital | |
| |envelope | |
+---------------------------------------------------+---------------------+---------+
|urn:ietf:params:acme:error:invalidKeyUsage |KeyUsage does not |RFC XXXX |
| |meet dual-certificate| |
| |requirements | |
+---------------------------------------------------+---------------------+---------+
|urn:ietf:params:acme:error:invalidCSR |finalize request for |RFC XXXX |
| |encryption | |
| |certificate Order | |
| |contains CSR | |
+---------------------------------------------------+---------------------+---------+
|urn:ietf:params:acme:error:invalidSM2Signature |SM2 signature |RFC XXXX |
| |verification failed | |
| |(e.g., r/s out of | |
| |range or invalid | |
| |format). | |
| |Semantically distinct| |
| |from the standard | |
| |error type | |
| |badSignatureAlgorithm| |
| |(for unsupported JWS | |
| |signature algorithms)| |
| |defined in [RFC8555] | |
| |Section 6.7 | |
+---------------------------------------------------+---------------------+---------+
|urn:ietf:params:acme:error:signingCertRequired |No valid signature |RFC XXXX |
| |certificate found | |
| |corresponding to | |
| |authKey | |
+---------------------------------------------------+---------------------+---------+
Table 3
Geng, et al. Expires 21 January 2027 [Page 26]
Internet-Draft ACME auth Challenge July 2026
*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.
+======================+=============================+===========+
| Extension Name | Suggested Permanent OID | Assigning |
| | | Authority |
+======================+=============================+===========+
| id-sm2-auth-key-hash | 1.2.156.10197.6.3.1 | CCSTC |
| | (suggested, [GMT.0015-2023] | |
| | certificate extension arc) | |
+----------------------+-----------------------------+-----------+
Table 4
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.
Geng, et al. Expires 21 January 2027 [Page 27]
Internet-Draft ACME auth Challenge July 2026
5.5. JOSE Registration
IANA is requested to register the following curve in the "JSON Web
Key Elliptic Curve" registry (established by [RFC7518]):
+===========+==========================================+===========+
| Curve | Description | Reference |
| Name | | |
+===========+==========================================+===========+
| sm2p256v1 | SM2 elliptic curve (parameters defined | RFC XXXX |
| | in [GMT.0003.5-2012]/[GBT.32918.5]; name | |
| | follows the naming convention used by | |
| | implementations such as GmSSL/OpenSSL) | |
+-----------+------------------------------------------+-----------+
Table 5
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):
+=================+============+==============+===========+
| Field Name | Field Type | Configurable | Reference |
+=================+============+==============+===========+
| authKey | object | true | RFC XXXX |
+-----------------+------------+--------------+-----------+
| includeEnvelope | boolean | true | RFC XXXX |
+-----------------+------------+--------------+-----------+
| envelope | string | false | RFC XXXX |
+-----------------+------------+--------------+-----------+
Table 6
6. Security and Operational Considerations
The security requirements in this section apply to SM-specific trust
system deployments.
Geng, et al. Expires 21 January 2027 [Page 28]
Internet-Draft ACME auth Challenge July 2026
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.
Geng, et al. Expires 21 January 2027 [Page 29]
Internet-Draft ACME auth Challenge July 2026
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.
Geng, et al. Expires 21 January 2027 [Page 30]
Internet-Draft ACME auth Challenge July 2026
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.
Geng, et al. Expires 21 January 2027 [Page 31]
Internet-Draft ACME auth Challenge July 2026
*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. Design Considerations
This section is non-normative and aims to clarify the key
architectural trade-offs and their rationales made in this document
under the hard constraint of the SM2 dual-certificate system.
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.
Geng, et al. Expires 21 January 2027 [Page 32]
Internet-Draft ACME auth Challenge July 2026
* *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*
Geng, et al. Expires 21 January 2027 [Page 33]
Internet-Draft ACME auth Challenge July 2026
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:
Geng, et al. Expires 21 January 2027 [Page 34]
Internet-Draft ACME auth Challenge July 2026
* *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. Future Considerations
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.
Geng, et al. Expires 21 January 2027 [Page 35]
Internet-Draft ACME auth Challenge July 2026
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. References
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.
Geng, et al. Expires 21 January 2027 [Page 36]
Internet-Draft ACME auth Challenge July 2026
[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>.
Geng, et al. Expires 21 January 2027 [Page 37]
Internet-Draft ACME auth Challenge July 2026
[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.
Appendix A. Protocol Interaction Diagrams
A.1. Signature Certificate Order Flow (Standard CSR Approach)
Geng, et al. Expires 21 January 2027 [Page 38]
Internet-Draft ACME auth Challenge July 2026
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 |
|<------------------------------|
Figure 1: Signature Certificate Order Flow (Standard CSR Approach)
A.2. Signature Certificate Order Flow (Using pk-01 Challenge)
Geng, et al. Expires 21 January 2027 [Page 39]
Internet-Draft ACME auth Challenge July 2026
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 |
|<----------------------------------------------|
Figure 2: Signature Certificate Order Flow (Using `pk-01` Challenge)
A.3. Encryption Certificate Order Flow (Using auth-01 Challenge)
Geng, et al. Expires 21 January 2027 [Page 40]
Internet-Draft ACME auth Challenge July 2026
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
Figure 3: Encryption Certificate Order Flow (Using `auth-01`
Challenge)
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.
Geng, et al. Expires 21 January 2027 [Page 41]
Internet-Draft ACME auth Challenge July 2026
*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:
Geng, et al. Expires 21 January 2027 [Page 42]
Internet-Draft ACME auth Challenge July 2026
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.
Geng, et al. Expires 21 January 2027 [Page 43]
Internet-Draft ACME auth Challenge July 2026
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*
Geng, et al. Expires 21 January 2027 [Page 44]
Internet-Draft ACME auth Challenge July 2026
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": "..."
}
Geng, et al. Expires 21 January 2027 [Page 45]
Internet-Draft ACME auth Challenge July 2026
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
+------------------------------------------------+
Geng, et al. Expires 21 January 2027 [Page 46]
Internet-Draft ACME auth Challenge July 2026
| 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 | +------------------------+
+------------------------+
Appendix B. Implementation Notes
This appendix is non-normative and provides core guidance for
implementers of this document.
Geng, et al. Expires 21 January 2027 [Page 47]
Internet-Draft ACME auth Challenge July 2026
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.
Geng, et al. Expires 21 January 2027 [Page 48]
Internet-Draft ACME auth Challenge July 2026
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.
Geng, et al. Expires 21 January 2027 [Page 49]
Internet-Draft ACME auth Challenge July 2026
*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.
Geng, et al. Expires 21 January 2027 [Page 50]
Internet-Draft ACME auth Challenge July 2026
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.
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 51]