]> Huawei Technologies

gengfeng@huawei.com

Huawei Technologies

wupanyu3@huawei.com

Huawei Technologies

wang.guilin@huawei.com

TrustAsia

palos.chen@trustasia.com

Automated Certificate Management Environment Working Group This document describes the extension of the ACME protocol 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 , 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 . 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.

Introduction

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

Background The Automatic Certificate Management Environment (ACME) protocol provides a standardized mechanism for automated certificate issuance and management. The ACME core resource model defines an Order as a request for a single certificate. Each Order contains the identifiers to be certified, the authorizations that must be completed, and the final certificate URL. In the China's Commercial Cryptography certificate system (defined in ), the SM2 dual-certificate architecture is adopted: each entity holds a signature certificate (for identity authentication and digital signatures) and an encryption certificate (for data encryption and key agreement). The two certificates are issued to the same entity but serve different security purposes and are subject to different key management policies. A notable feature of the SM2 dual-certificate system is that the encryption private key is generated by the Key Management Center (KMC) and securely delivered to the end entity. The KMC encrypts the encryption private key using the entity's signature public key via a digital envelope (as defined in ), 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.

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.

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.

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

Scope and Positioning Note on Key Escrow Positioning: The security model of assumes that certificate private keys are generated locally by the client and do not leave the client's trust boundary. The mechanism described in this document, whereby the encryption private key is centrally generated and escrowed by the KMC, is a mandatory requirement imposed by and related regulatory frameworks for encryption certificates. This document merely provides an ACME protocol-level adaptation for this established regulatory fact and does not constitute a general recommendation for key escrow architectures, nor does it alter the principle that the signature certificate private key must be generated by the client and remain within its trust boundary. The extension mechanism described in this document is applicable only to dedicated trust systems that comply with GM/T series standards. This document is not applicable to public-trust TLS certificate systems such as the Web PKI governed by the CA/Browser Forum. Note on Terminology: The term “dual-certificate system” in this document refers specifically to the SM2 architecture defined in , 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.

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

SM2 Dual-Certificate Workflow

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

Signature Certificate Request Flow The signature certificate request fully follows the standard ACME workflow. The client may choose either of the following options: Option 1: Standard CSR Approach

1. The client creates an Order.
2. The client completes the required authorization challenges (e.g., HTTP-01, DNS-01).
3. The client submits a CSR containing the signature public key to the finalize endpoint.
4. The server validates the CSR and issues the signature certificate.

Option 2: Using the pk-01 Challenge (Optional) This option is an optimization. The client SHOULD use the standard CSR approach as the primary method. If the server and client support the pk-01 challenge defined in , 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.

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.

Digital Envelope Format Specification The digital envelope SHOULD comply with the following specifications: Data Type: It is RECOMMENDED to use the signedAndEnvelopedData type defined in Section 10 of , 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 ) 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 . 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 ). This OID implicitly uses the Key Derivation Function (KDF) specified in Section 4 of ; the KDF output length matches the SM4 key length (128 bits), with specific parameters as specified in Section 4.2 of . Implementers need not specify a separate KDF OID. EncryptedContentInfo:

• The contentEncryptionAlgorithm field SHOULD use the SM4-CBC algorithm OID defined in .
• 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 . The SM4 symmetric key MUST be generated using a hardware random number generator compliant with , or an equivalent security standard; its output SHOULD pass the randomness tests specified in , 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.

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 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 . KMC signature certificate trust anchor configuration, lifecycle management, and communication security requirements between the ACME server and the KMC are described in Section 6.

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 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 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 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 Section 7.1.3/Section 7.4, nor MUST it be counted in certificate revocation authorization determinations under 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.
• 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. 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 ), 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 . 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: 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: 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 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 . 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.
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 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 , with the following specific requirements:

• kty MUST be "EC".
• crv MUST be "sm2p256v1" (lowercase; curve parameters are defined in , and this name follows the naming convention used by widely deployed implementations such as GmSSL/OpenSSL).
• 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 , they may also be passed via its Order metadata extension mechanism. Payload example: 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):

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

Design Note: The Nature of the auth-01 Authorization Object 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.

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.
• 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. The example above shows the response when the client sets includeEnvelope: true; otherwise, the server omits the envelope field. 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.

Extension Specifications

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 ) 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 ).
• 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 ). 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 Section 2.2 and .

The KMC uses this public key to encrypt the encryption private key via a digital envelope compliant with . SubjectPublicKeyInfo Encoding Compatibility: When parsing this structure, the KMC MUST give priority to the 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.

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: 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 ). When generating, the parameters field SHOULD be encoded as NULL; when parsing, implementations MUST be able to parse NULL and SHOULD also support omission of the parameters field.
• hashValue: A 32-byte OCTET STRING containing the SM3 hash of the authorizing signature public key.

Criticality Flag: This extension MUST be marked as non-critical (critical = FALSE). Authoritativeness of the Extension: The sm2AuthKeyHash extension is the authoritative basis for the binding in the GM dual-certificate system. Relying parties MUST verify the presence and hash consistency of this extension when validating encryption certificates issued under this specification. If the extension is present and the hash does not match, the relying party MUST treat it as a security violation and reject the encryption certificate. Extension Inclusion Policy: Encryption certificates issued under this specification MUST include this extension. OID Assignment: The OID for this extension (id-sm2-auth-key-hash) uses the temporary OID 1.3.6.1.4.1.2011.2.467.1.3 during the standardization phase. Upon standardization, a permanent OID will be requested under 1.2.156.10197.6.3.1 (within the certificate extension arc of ), subject to confirmation of availability with the CCSTC.

IANA Considerations

New ACME Challenge Type IANA is requested to register the following new challenge type in the "ACME Validation Methods" registry (established by Section 9.7.8):

Label	Identifier Type	ACME	Reference
auth-01	dns (reuses the first identifier of the Order; this challenge does not validate identifier control; see Section 3.3.2)	Y	RFC XXXX

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.

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

Error Type	Description	Reference
urn:ietf:params:acme:error:authKeyMissing	authKey field missing from JWS Payload of newOrder request	RFC XXXX
urn:ietf:params:acme:error:kmcUnavailable	KMC temporarily unavailable	RFC XXXX
urn:ietf:params:acme:error:envelopeGenerationFailed	KMC failed to generate digital envelope	RFC XXXX
urn:ietf:params:acme:error:invalidKeyUsage	KeyUsage does not meet dual-certificate requirements	RFC XXXX
urn:ietf:params:acme:error:invalidCSR	finalize request for encryption certificate Order contains CSR	RFC XXXX
urn:ietf:params:acme:error:invalidSM2Signature	SM2 signature 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 Section 6.7	RFC XXXX
urn:ietf:params:acme:error:signingCertRequired	No valid signature certificate found corresponding to authKey	RFC XXXX

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.

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 (suggested, certificate extension arc)	CCSTC

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.

JOSE Registration IANA is requested to register the following curve in the "JSON Web Key Elliptic Curve" registry (established by ):

Curve Name	Description	Reference
sm2p256v1	SM2 elliptic curve (parameters defined in /; name follows the naming convention used by implementations such as GmSSL/OpenSSL)	RFC XXXX

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.

ACME Order Object Field Registration IANA is requested to register the following fields in the "ACME Order Object Fields" registry (established by 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

Security and Operational Considerations The security requirements in this section apply to SM-specific trust system deployments.

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

Key Usage Separation Per , signature keys and encryption keys serve different purposes. The client's signature private key is only used for ACME account authentication, signing in auth-01 challenges, and decrypting the digital envelope. The signature private key MUST NOT be used for data encryption or decryption operations. The encryption private key is only used for data encryption and decryption. The server MUST verify that there is no direct association between the private key used for the auth-01 challenge and the public key in the final encryption certificate, and MUST NOT use the signature public key from authKey as the public key for the encryption certificate.

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.

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 . When returning a finalize response containing the envelope field, the server MUST ensure that the endpoint is not cached in any caching architecture. Deployments SHOULD explicitly disable caching via CDN configuration and apply application-layer protection to the envelope field content. The envelope field is delivered only when the client explicitly sets includeEnvelope: true (default false); the server MUST NOT return the envelope field when the client has not explicitly requested it. If the client did not request the envelope but later needs the encryption private key, it SHOULD re-initiate the encryption certificate request with includeEnvelope: true. Re-requesting will generate a new encryption certificate and escrowed key pair: the CA SHOULD associate encryption certificates of the same entity via authKey and revoke previously issued encryption certificates that are still valid upon re-issuance. The CA SHOULD revoke the superseded encryption certificate and SHOULD apply rate limiting to repeated requests from the same entity.

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.

KMC Compliance and Certificate Revocation KMC Separation of Duties and Single Point of Trust Model: As a trusted subsystem of the CA, the KMC's operations MUST be subject to the CA's overall audit and compliance framework. There SHOULD be a separation of duties between the KMC and the CA —the CA is responsible for certificate issuance, and the KMC is responsible for key escrow, with mutual checks and balances. The KMC's key escrow operations SHOULD be included in the CA's annual WebTrust or SOC 2 audit scope. The KMC holds all encryption private keys, constituting a high-value attack target. For deployments with higher requirements regarding single point of trust risk, threshold KMC or key sharding schemes are RECOMMENDED; when adopting such schemes, their security model SHOULD be consistent with the threat model of this document. Certificate Revocation Linkage Policy: The CA SHOULD define a linkage policy for revoking signature and encryption certificates. When a signature certificate is revoked, the CA SHOULD consider revoking the corresponding encryption certificate; when an encryption certificate is revoked, the signature certificate MAY remain unaffected. The revocation linkage policy SHOULD be clearly stated in the CA's CP/CPS. Note: The audit and CRL/OCSP publication mechanisms for revocation linkage policies SHOULD be clearly specified in the CA's CP/CPS. If revocation of a signature certificate triggers revocation of an encryption certificate, it is RECOMMENDED that the decision rationale be recorded in the audit log for subsequent traceability. Escrowed Private Key Deletion Policy: When an encryption certificate is revoked, expires, or is superseded by a newly requested certificate, the KMC SHOULD delete the corresponding escrowed encryption private key within a reasonable timeframe (30 days is RECOMMENDED), unless laws or regulations require a longer retention period. Compliance: Deployments in SM trust systems SHOULD comply with the Cryptography Law, the Cybersecurity Law, , and relevant industry standards.

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.

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

• Single-Order Model: Request both certificates in a single Order, completing all authorizations and issuance in one go. While this approach appears to reduce the number of HTTP round trips, it deviates from the core semantics of RFC 8555, where an Order corresponds to a single certificate, and contradicts the long-standing consensus in the ACME community, leading to complex error handling and state management logic.
• Dual-Order Model (Selected): Create separate Orders for each certificate, strictly adhering to RFC 8555's resource model. The signature certificate Order reuses the standard ACME workflow; the encryption certificate Order completes identity authorization through the new auth-01 challenge. This choice maintains maximum compatibility with existing ACME clients and servers, achieves clear error isolation, and ensures long-term maintainability and extensibility of the solution.

Authorization Object Reuse vs. New Order-Level Field Two approaches were considered for carrying identity authorization within the ACME framework. Option A: Dedicated Authorization Object with auth-01 Challenge (Selected) This approach reuses RFC 8555's existing authorization and challenge infrastructure without introducing new resource types. The dedicated authorization object follows the standard state machine (pending → valid/invalid), and its special nature—not counting toward identifier authorization reuse—is enforced by server policy, not by protocol modification. Option B: New Order-Level Field (e.g., identityAuthorizations) This approach would introduce a new field at the Order level, separating identity authorization from identifier authorization at the data model level. While architecturally cleaner in terms of semantic separation, it carries significant costs:

• Requires defining new resource types with their own lifecycle and state management.
• Increases implementation burden and adoption barriers for both servers and clients.
• Breaks the "minimal extension footprint" narrative of this document.

Rationale for Selected Approach Option A is selected because it achieves the functional goal—requiring both identifier and identity authorization before an encryption certificate Order can be finalized—while maximizing reuse of the existing RFC 8555 resource model. The semantic distinction is enforced by server policy, not by state machine modification. This allows the extension to operate within the RFC 8555 framework without altering core protocol semantics. The dedicated authorization object pattern also serves as a reusable template for other ACME extensions requiring non-identifier-based authorization or multiple independent authorization factors within a single Order (see Design Note in Section 3.3.2).

Identity Authorization vs. Identifier Authorization 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 authorization state machine.

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.

Auditability of Key Escrow Key escrow has historically been controversial within the IETF community. The mechanism described here is a mandatory requirement of and related regulatory frameworks for encryption certificates. This document provides an ACME protocol adaptation for that established requirement and does not constitute a general recommendation for key escrow architectures. This design provides two safeguards intended to make key escrow auditable and verifiable in the SM context:

• Cryptographic Binding: The auth-01 challenge and sm2AuthKeyHash extension establish a verifiable binding between the encryption certificate and the signature certificate. A relying party can extract sm2AuthKeyHash, compute the SM3 hash of the expected signature-certificate public key as specified in Section 4.2, and compare the values.
• Separation of Duties: The CA is responsible for certificate issuance and the KMC for key escrow. KMC escrow operations SHOULD be included in the CA's annual WebTrust or SOC 2 audit scope. Where the KMC is operated by a third party, the responsibility boundary and compliance allocation between the CA and KMC SHOULD be clearly defined.

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

Future Considerations

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.

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

References Normative References State Cryptography Administration State Cryptography Administration State Cryptography Administration State Cryptography Administration State Cryptography Administration State Cryptography Administration State Cryptography Administration State Cryptography Administration State Cryptography Administration State Cryptography Administration Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. Informative References Huawei Technologies Huawei Technologies Huawei Technologies TrustAsia The Automatic Certificate Management Environment (ACME) [RFC8555] requires a PKCS#10 Certificate Signing Request (CSR) at the finalization stage. This document defines a new ACME challenge type, "pk-01", that allows a client to prove possession of a private key directly, without constructing a CSR. The primary motivation is to support key types that cannot generate CSR self-signatures, notably post-quantum Key Encapsulation Mechanism (KEM) keys. The client declares the public key via a popKey field in the "newOrder" request; the server attaches the "pk-01" challenge to existing identifier authorizations. When all required authorizations are satisfied, the ACME server issues a certificate using the validated public key and the authorized identifiers, eliminating the need for a CSR in the finalization stage. Internet Security Research Group This document defines how an ACME Server may offer a selection of different certificate profiles to ACME Clients, and how those clients may indicate which profile they want. State Administration for Market Regulation State Cryptography Administration

Protocol Interaction Diagrams

Signature Certificate Order Flow (Standard CSR Approach)

Signature Certificate Order Flow (Standard CSR Approach) | | | | 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 | |<------------------------------| ]]>

Signature Certificate Order Flow (Using pk-01 Challenge)

Signature Certificate Order Flow (Using `pk-01` Challenge) | | | | 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 | |<----------------------------------------------| ]]>

Encryption Certificate Order Flow (Using auth-01 Challenge)

Encryption Certificate Order Flow (Using `auth-01` Challenge) | | | | | | 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 ]]>

Complete HTTP Interaction Example (Normal Flow) The following example shows the complete HTTP interaction for requesting an encryption certificate using the auth-01 challenge. Step 1: Create Order (newOrder) The decoded payload is: Step 2: Server Returns Order and Challenges 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: 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.

The decoded payload is: Step 4: Submit finalize Request and Retrieve Envelope Step 5: Retrieve Encryption Certificate

Error Scenario HTTP Interaction Examples Error Scenario 1: KMC Unavailable Error Scenario 2: finalize Request for Encryption Certificate Order Contains CSR Error Scenario 3: SM2 Signature r or s Out of Range

Error Handling Flow

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

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

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

1. Obtain kid from the JWS header, look up the corresponding account public key, verify the JWS signature, and confirm that the account is the account that created the Order.
2. Obtain the account JWK from the account state stored when the Order was created and compute account_thumbprint according to RFC 7638; do not extract this value from authSignature or the challenge response.
3. Extract the signature value from authSignature, verify that the token matches the challenge object and has not been used.
4. Using the account_thumbprint computed in Step 2, construct the signature input message = "ACME auth-01" || 0x00 || challenge_url || 0x00 || token_utf8_bytes || 0x00 || account_thumbprint.
5. Compute hash = SM3(message) and verify the signature using the public key from authKey.
6. Verify that both r and s are in the range [1, n-1] and that s <= n/2.
7. Verify that the signing public key matches the authKey declared in the newOrder request.
8. Verify that the account identified by kid matches the account corresponding to authKey.

If the account key was changed before challenge completion, the server MUST reject the challenge response, transition the affected incomplete auth-01 authorization object and its Order to invalid, and MUST NOT use the new account key's thumbprint to reconstruct the signature input for the old Order. Cache Control: When returning a finalize response containing the envelope field, the server MUST set the Cache-Control: no-store, private header and ensure that the finalize endpoint is explicitly disabled for caching at the CDN level. Audit Logs: The server SHOULD log all encryption certificate request operations, including auth-01 challenge completion, KMC invocation results, certificate issuance records, and envelope delivery records.

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.

KMC Core Guidance

1. The random number generator used for key generation MUST comply with , and its output MUST pass the randomness tests specified in .
2. The KDF output length parameter klen MUST be set to 128 bits (SM4 key length), with specific parameters as specified in Section 4.2.
3. When parsing the SubjectPublicKeyInfo structure passed by the server, implementations MUST comply with encoding specifications and MUST NOT support direct identification using the SM2 algorithm OID.
4. After an encryption certificate is revoked or expires, the escrowed private key SHOULD be deleted within a reasonable timeframe; the deletion period SHOULD be clearly stated in the CP/CPS (30 days is RECOMMENDED), and the deletion operation SHOULD be logged.
5. For deployments with higher requirements regarding single point of trust risk, threshold KMC or key sharding schemes are RECOMMENDED; when adopting such schemes, their security model SHOULD be consistent with the threat model of this document.