Internet-Draft COSE and JOSE ShangMi Algorithms October 2026
Liao, et al. Expires 3 May 2027 [Page]
Workgroup:
CBOR Object Signing and Encryption
Internet-Draft:
draft-liao-cose-sm-algorithms-00
Published:
Intended Status:
Informational
Expires:
Authors:
L. Liao
NIO Inc.
G. Wang
Huawei Int. Pte Ltd
H. Cai
Alibaba Cloud
X. Zhai
TrustAsia

COSE and JOSE Registrations for ShangMi (SM) Cryptographic Algorithms

Abstract

This document registers code points for the use of the Chinese ShangMi (SM) cryptographic algorithms with CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE): the elliptic curve curveSM2, the SM2 digital signature algorithm with the SM3 hash function, SM2 public key encryption for content key transport, HMAC-SM3, and the SM4 block cipher in GCM mode. For COSE, it additionally registers the SM3 hash function, key derivation with HKDF-SM3, and SM4 in CCM mode.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 3 May 2027.

▲

Table of Contents

1. Introduction

The ShangMi (SM) algorithms are a set of cryptographic algorithms published by the Chinese government and adopted by ISO/IEC: the elliptic curve public key algorithm SM2 [ISO-SM2], the hash function SM3 [ISO-SM3], and the block cipher SM4 [ISO-SM4]. [RFC8998] specifies how these algorithms are used in TLS 1.3.

CBOR Object Signing and Encryption (COSE) [RFC9052] [RFC9053] uses algorithm identifiers and elliptic curve identifiers registered in the "COSE Algorithms" and "COSE Elliptic Curves" registries [IANA.COSE]. No identifiers for the ShangMi algorithms have been registered so far. The same holds for JSON Object Signing and Encryption (JOSE) [RFC7515] [RFC7516] [RFC7517] [RFC7518] and its "JSON Web Signature and Encryption Algorithms" and "JSON Web Key Elliptic Curve" registries [IANA.JOSE]. This document fills that gap: it defines how the SM algorithms are used with COSE and with JOSE and requests the corresponding registrations. Like [RFC8812] and [RFC9864], it covers both COSE and JOSE in one document.

This document follows the patterns established by earlier COSE algorithm documents: [RFC9053] for signature, MAC, content encryption, and key distribution algorithms; [RFC9054] and [RFC9861] for hash functions; and [RFC9864] for fully-specified algorithm identifiers.

The COSE algorithms defined in this document are:

Table 1: COSE Algorithms Defined in This Document
Name Section Purpose
SM2-SM3 Section 3.1 Signature
SM3 Section 4 Hash
HMAC-SM3 Section 5 MAC
SM4-GCM Section 6.1 Content encryption, AEAD
SM4-CCM-16-64-128 Section 6.2 Content encryption, AEAD
SM4-CCM-16-128-128 Section 6.2 Content encryption, AEAD
direct+HKDF-SM3 Section 7 Key derivation
SM2-ENC-SM3 Section 8.1 Key transport

The JOSE algorithms defined in this document are:

Table 2: JOSE Algorithms Defined in This Document
Name Usage Section Purpose
SM2-SM3 alg Section 9.2 JWS signature
HS-SM3 alg Section 9.3 JWS MAC
SM4GCM enc Section 9.4 JWE content encryption
SM2-ENC-SM3 alg Section 9.5 JWE key encryption

In addition, this document registers the elliptic curve curveSM2 for both COSE (Section 2) and JOSE (Section 9.1).

The following algorithms are intentionally not defined in this document:

These algorithms can be specified in a separate document if a need arises.

1.1. Motivation

In China, the use of the SM algorithms is promoted by law and by national standards. The Cryptography Law of the People's Republic of China [CRYPTO-LAW] establishes the framework for commercial cryptography, and national standards such as [GBT.39786-2021] specify the basic requirements for the use of cryptography in information systems, based on the SM algorithms. Products and services deployed in China are therefore often required, or at least recommended, to protect data with the SM algorithms. Without registered code points, such deployments cannot use COSE and JOSE in an interoperable way and resort to private-use or proprietary identifiers.

A prominent example is the intelligent and connected vehicle. The draft mandatory national standard "Technical requirements for vehicle cryptography application" [VEHICLE-CRYPTO], proposed by the Ministry of Industry and Information Technology and the State Cryptography Administration, requires that the cryptographic algorithms used in vehicles conform to national, industry, or international cryptographic standards and meet the requirements of the national cryptography administration. It requires digital signatures or message authentication codes for, among others, secure boot, software updates, remote control, diagnostics, and communication with cloud platforms, and it requires encryption to protect important data and sensitive personal information.

COSE is particularly well suited to the vehicle. Many electronic control units (ECUs) are constrained devices, and in-vehicle networks such as CAN and CAN FD carry only small frames at limited bandwidth. The compact binary encoding of CBOR and the small overhead of COSE fit these conditions better than text-based formats. COSE can be used in the vehicle, for example, for:

  • verifying the authenticity and integrity of firmware and software during secure boot and software updates, including over-the-air updates, with Software Updates for Internet of Things (SUIT) manifests [I-D.ietf-suit-manifest], which implement the SUIT information model [RFC9124] and are protected with COSE;

  • protecting the integrity of the records of event data recorders and of the data recording systems for automated driving, and of security logs, with COSE_Sign1 or COSE_Mac0;

  • protecting messages between ECUs, and between ECUs and diagnostic tools, with OSCORE [RFC8613], with keys established by EDHOC [RFC9528];

  • carrying authorization for diagnostic and remote control access in CBOR Web Tokens (CWTs) [RFC8392]; and

  • attesting the state of ECUs with Entity Attestation Tokens [RFC9711].

JOSE, on the other hand, is widely used in the interaction between vehicles, cloud platforms such as telematics service provider (TSP) and over-the-air update (OTA) platforms, mobile applications, and third-party services, which is mostly based on HTTP and JSON. Typical uses are:

  • access tokens for the APIs of cloud platforms, such as OAuth 2.0 access tokens in the JSON Web Token (JWT) format [RFC7519] [RFC9068];

  • signing remote control commands that are issued by a mobile application and relayed through a cloud platform to the vehicle, with JWS; and

  • encrypting important data and sensitive personal information sent from the vehicle to the cloud platform, with JWE.

Transport security such as TLS or TLCP [GBT.38636-2020] protects data only between the endpoints of each connection. COSE and JOSE protect the objects themselves, so that the protection is maintained end to end across intermediaries such as cloud platforms, and while the data is stored.

The code points registered by this document allow these technologies to be used with the SM algorithms.

1.2. Requirements Notation and Conventions

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.

1.3. Terminology

The terms "COSE_Key", "COSE_Sign1", "COSE_Mac0", "COSE_Encrypt0", "COSE_Encrypt", "COSE_recipient", "Sig_structure", "MAC_structure", "Enc_structure", and "COSE_KDF_Context" are used as defined in [RFC9052] and [RFC9053]. The terms "JWS Signing Input", "JWS Signature", "JWE Encrypted Key", "JWE Initialization Vector", "JWE Ciphertext", "JWE Authentication Tag", and "Additional Authenticated Data (AAD)" are used as defined in [RFC7515] and [RFC7516].

COSE key operation values are given by their name in Table 5 of [RFC9052], followed by their integer value in parentheses, e.g., "MAC create" (9). In a COSE_Key, the "key_ops" parameter contains the integer values.

SM3(x):

The SM3 hash of the octet string x, a 32-octet value.

x || y:

The concatenation of the octet strings x and y.

I2OSP(x, l):

The big-endian, l-octet representation of the non-negative integer x.

2. The Elliptic Curve curveSM2

The elliptic curve curveSM2 is the 256-bit prime field Weierstrass curve y^2 = x^3 + ax + b defined in [GBT.32918.5-2017] and [ISO-SM2]. It is the curve that [RFC8998] uses for signatures and key exchange in TLS 1.3, and this document uses the same name. The curve is also known as sm2p256v1 and is identified by the object identifier 1.2.156.10197.1.301 [GMT.0006-2012]. Its parameters are:

p  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
     FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
a  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
     FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
b  = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7
     F39789F5 15AB8F92 DDBCBD41 4D940E93
n  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
     7203DF6B 21C6052B 53BBF409 39D54123
Gx = 32C4AE2C 1F198119 5F990446 6A39C994
     8FE30BBF F2660BE1 715A4589 334C74C7
Gy = BC3736A2 F4F6779C 59BDCEE3 6B692153
     D0A9877C C62A4740 02DF32E5 2139F0A0
h  = 1
Figure 1: Parameters of curveSM2

Here p is the field prime, a and b are the curve coefficients, n is the order of the base point G = (Gx, Gy), and h is the cofactor.

2.1. COSE Key Representation

Keys on curveSM2 use the "EC2" key type defined in Section 7.1 of [RFC9053]. The "crv" key parameter is set to curveSM2 (TBD1). The "x", "y", and "d" parameters each contain a 32-octet value, encoded as specified for EC2 keys in [RFC9053]. Point compression ("y" encoded as a Boolean) MAY be used as specified there.

The same curveSM2 key pair SHOULD NOT be used with both SM2-SM3 and SM2-ENC-SM3. A COSE_Key for curveSM2 SHOULD contain the "alg" parameter to restrict the key to one algorithm.

3. Signature Algorithm

3.1. SM2 with SM3

This section defines the use of the SM2 digital signature algorithm [ISO-SM2] [GBT.32918.2-2016] on curveSM2 with the SM3 hash function. The algorithm identifier is fully specified in the sense of [RFC9864]: it determines both the curve and the hash function.

Table 3: SM2 Signature Algorithm Value
Name Value Description
SM2-SM3 TBD2 SM2 signature using curveSM2 and SM3

3.1.1. Distinguishing Identifier

The SM2 signature algorithm hashes a value Z, which binds the signature to the public key and to a distinguishing identifier ID of the signer:

Z = SM3(ENTL || ID || a || b || Gx || Gy || xA || yA)

ENTL is the bit length of ID, encoded as a 2-octet big-endian integer. a, b, Gx, and Gy are the curve parameters from Section 2, and (xA, yA) is the signer's public key. All of these field elements are encoded as 32-octet big-endian values.

For COSE, ID MUST be the 16-octet ASCII string "1234567812345678" (0x31, 0x32, ..., 0x38, 0x31, ..., 0x38), which is the default identifier defined in [GMT.0009-2012]. This document does not define a way to signal a different identifier.

This follows the approach taken for other COSE signature algorithms whose underlying primitive accepts an additional context input: ML-DSA-44, ML-DSA-65, and ML-DSA-87 [RFC9964] require the "ctx" parameter to be the empty string, and Ed448 [RFC9053] [RFC9864] provides no means to signal a context, so the empty context is used. For SM2, the default identifier plays the role of the empty context: it is the value that SM2 implementations use when no identifier is configured, so it ensures interoperability. Domain separation and binding to application data are achieved, as for the other COSE signature algorithms, through the protected header parameters and the external_aad of the Sig_structure ([RFC9052]).

3.1.2. Signing and Verification

Signing a COSE object with SM2-SM3 uses the procedure in Section 4.4 of [RFC9052]. The message M to be signed is the encoded Sig_structure (ToBeSigned). The signer:

  1. computes e = SM3(Z || M), interpreted as a big-endian integer;

  2. generates a fresh random integer k in [1, n-1] and computes (x1, y1) = [k]G;

  3. computes r = (e + x1) mod n. If r = 0 or r + k = n, it returns to step 2;

  4. computes s = ((1 + dA)^-1 * (k - r * dA)) mod n, where dA is the private key. If s = 0, it returns to step 2.

The signature is the 64-octet string I2OSP(r, 32) || I2OSP(s, 32). This is the same encoding as for ECDSA in Section 2.1 of [RFC9053]. The signature is not ASN.1 DER encoded.

The verifier checks that r and s are in [1, n-1], computes e as above, t = (r + s) mod n, and (x1', y1') = [s]G + [t]PA, where PA is the public key. The signature is valid if (e + x1') mod n = r and t is not 0.

The SM3 hash over Z || M is part of the signature algorithm. Implementations whose cryptographic interface takes a precomputed hash MUST pass e = SM3(Z || M) to that interface, not SM3(M).

3.1.3. Key Requirements

When a COSE key is used with SM2-SM3, the following checks are made:

  • The "kty" field MUST be present and MUST be "EC2".

  • The "crv" field MUST be present and MUST be curveSM2.

  • If the "alg" field is present, it MUST be SM2-SM3.

  • If the "key_ops" field is present, it MUST include "sign" (1) when signing and "verify" (2) when verifying.

4. Hash Algorithm

This section registers the SM3 hash function [ISO-SM3] [GBT.32905-2016] for use with COSE, for example in the hash structures of [RFC9054] or in the COSE_CertHash structure of [RFC9360]. SM3 produces a 256-bit hash value.

Table 4: SM3 Hash Algorithm Value
Name Value Description
SM3 TBD3 SM3 256-bit Hash

SM3 does not take a key. As specified for the hash functions in [RFC9054], the COSE capabilities array for SM3 is therefore empty (see Section 8 of [RFC9053]).

5. Message Authentication Code Algorithm

This section defines the use of HMAC [RFC2104] with the SM3 hash function. HMAC-SM3 is used as described for HMAC in Section 3.1 of [RFC9053], with SM3 in place of the SHA-2 hash function.

Table 5: HMAC-SM3 Algorithm Value
Name Value Description
HMAC-SM3 TBD4 HMAC w/ SM3

As for HMAC with SHA-256 in Section 3.1 of [RFC9053], the key size depends on how the key is obtained. For recipient algorithms that transport the key (such as SM2-ENC-SM3), the size of the HMAC key SHOULD be the same as the size of the SM3 output, i.e., 256 bits. For recipient algorithms that derive the key (such as direct+HKDF-SM3), the derived key MUST be 256 bits long. Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.

The authentication tag is the full 256-bit HMAC output.

When a COSE key is used with HMAC-SM3, the following checks are made:

6. Content Encryption Algorithms

SM4 [ISO-SM4] [GBT.32907-2016] is a block cipher with a 128-bit block size and a 128-bit key. The algorithms in this section use SM4 in place of AES in the authenticated encryption modes already used by COSE.

6.1. SM4-GCM

SM4 in Galois/Counter Mode [GCM] is used as described for AES-GCM in Section 4.1 of [RFC9053], with the following parameters:

  • The key is 128 bits.

  • The nonce is 96 bits. It is carried in the "IV" header parameter, or is computed from the "Partial IV" header parameter and the base IV of the key, as described in Section 3.1 of [RFC9052].

  • The authentication tag is 128 bits. The tag is appended to the ciphertext.

Table 6: SM4-GCM Algorithm Value
Name Value Description
SM4-GCM TBD5 SM4-GCM mode w/ 128-bit key, 128-bit tag

The same nonce and key combination MUST NOT be used more than once.

These parameters are the same as for the TLS_SM4_GCM_SM3 cipher suite of [RFC8998], whose test vectors therefore also apply to SM4-GCM.

6.2. SM4-CCM

SM4 in Counter with CBC-MAC mode [CCM] [RFC3610] is used as described for AES-CCM in Section 4.2 of [RFC9053]. As with AES-CCM, two parameters are chosen per algorithm: L, the size in bits of the length field, which determines the nonce size (15 - L/8 octets), and M, the size in bits of the authentication tag.

The naming convention "SM4-CCM-L-M-K" follows that of AES-CCM in [RFC9053], where K is the key size in bits.

Table 7: SM4-CCM Algorithm Values
Name Value L M Nonce Size (octets)
SM4-CCM-16-64-128 TBD6 16 64 13
SM4-CCM-16-128-128 TBD7 16 128 13

The nonce is carried in the "IV" header parameter, or is computed from the "Partial IV" header parameter and the base IV of the key. The same nonce and key combination MUST NOT be used more than once.

Unlike AES-CCM in [RFC9053], only variants with L = 16 are defined. With L = 16, the nonce is 13 octets (104 bits) long, and a message is limited to 2^16 - 1 octets of plaintext. This suits the use cases of SM4-CCM in COSE, which are constrained environments with short messages, such as OSCORE [RFC8613] and EDHOC [RFC9528]; the AES-CCM variants used there also have L = 16. Variants with L = 64 are not defined for the following reasons:

  • Messages of more than 2^16 - 1 octets are not expected in these environments. Applications that need to encrypt larger content can use SM4-GCM.

  • With L = 64, the nonce is only 7 octets (56 bits) long, which is too short for nonces to be generated at random.

  • No use of these variants is known.

The TLS_SM4_CCM_SM3 cipher suite of [RFC8998] uses a 12-byte nonce, which corresponds to L = 24. That combination is not defined here either, because COSE AES-CCM does not use it.

6.3. Key Requirements for SM4 AEAD Algorithms

When a COSE key is used with SM4-GCM or SM4-CCM, the following checks are made:

  • The "kty" field MUST be present and MUST be "Symmetric".

  • The key MUST be 128 bits long.

  • If the "alg" field is present, it MUST match the algorithm being used.

  • If the "key_ops" field is present, it MUST include "encrypt" (3) or "wrap key" (5) when encrypting, and "decrypt" (4) or "unwrap key" (6) when decrypting.

7. Key Derivation Algorithm

This section defines the use of HKDF [RFC5869] with HMAC-SM3 as a direct key derivation algorithm. direct+HKDF-SM3 is used as described for direct+HKDF-SHA-256 in Section 6.1.2 of [RFC9053], with HMAC-SM3 in place of HMAC-SHA-256.

Table 8: direct+HKDF-SM3 Algorithm Value
Name Value Description
direct+HKDF-SM3 TBD8 Shared secret w/ HKDF and SM3

The "info" input to HKDF is the encoded COSE_KDF_Context structure of Section 5.2 of [RFC9053]. The salt is taken from the "salt" header parameter if present; otherwise, a string of 32 zero octets is used, as specified in [RFC5869]. The "PartyU" and "PartyV" header parameters of Section 5.2 of [RFC9053] MAY be used.

The key requirements are those of Section 6.1.2 of [RFC9053].

The direct+HKDF-SM3 identifier also identifies HKDF-SM3 where a COSE algorithm identifier for an HMAC-based HKDF is needed, such as the HKDF Algorithm of an OSCORE Security Context (Section 3.1 of [RFC8613]; Section 3.2.1 of [RFC9203]).

8. Content Key Distribution Methods

8.1. SM2 Public Key Encryption with SM3

This section defines the use of the SM2 public key encryption algorithm [GBT.32918.4-2016] on curveSM2 as a key transport method (Section 8.5.3 of [RFC9052]), in the same way as RSAES-OAEP is used in COSE. The algorithm is used only in COSE_recipient structures; the plaintext is the content encryption key (CEK).

Table 9: SM2 Key Transport Algorithm Value
Name Value Description
SM2-ENC-SM3 TBD9 SM2 public key encryption using curveSM2 and SM3

8.1.1. Encryption

Given the recipient's public key PB on curveSM2 and the CEK of klen octets, the sender:

  1. generates a fresh random integer k in [1, n-1];

  2. computes C1 = [k]G = (x1, y1) and (x2, y2) = [k]PB;

  3. computes t = KDF(I2OSP(x2, 32) || I2OSP(y2, 32), klen). If t consists only of zero octets, it returns to step 1;

  4. computes C2 = CEK XOR t;

  5. computes C3 = SM3(I2OSP(x2, 32) || CEK || I2OSP(y2, 32)).

KDF is the key derivation function of [GBT.32918.4-2016] based on SM3: KDF(Z, klen) consists of the leftmost klen octets of SM3(Z || I2OSP(1, 4)) || SM3(Z || I2OSP(2, 4)) || ...

The "ciphertext" field of the COSE_recipient contains

C1 || C3 || C2

where C1 is encoded as an uncompressed point [GBT.32918.1-2016], i.e., the octet 0x04 followed by I2OSP(x1, 32) and I2OSP(y1, 32), and C3 is 32 octets. The ciphertext is thus 97 octets longer than the CEK. The ciphertext is not ASN.1 DER encoded. The order C1 || C3 || C2 is the one specified in [GBT.32918.4-2016]; the order C1 || C2 || C3 used by some early implementations MUST NOT be used.

8.1.2. Decryption

The recipient parses the ciphertext as C1 || C3 || C2, verifies that C1 is a point on curveSM2 other than the point at infinity, computes (x2, y2) = [dB]C1 with its private key dB, and recovers CEK = C2 XOR KDF(I2OSP(x2, 32) || I2OSP(y2, 32), klen). It then recomputes C3 and MUST reject the ciphertext if the value does not match. Implementations SHOULD NOT report which of these checks failed.

8.1.3. Header Parameters and Key Requirements

As for all key transport algorithms (Section 8.5.3 of [RFC9052]), the "protected" header of the COSE_recipient MUST be a zero-length byte string, and the "alg" header parameter is placed in the unprotected header. The recipient's key is typically identified by the "kid" header parameter.

When a COSE key is used with SM2-ENC-SM3, the following checks are made:

  • The "kty" field MUST be present and MUST be "EC2".

  • The "crv" field MUST be present and MUST be curveSM2.

  • If the "alg" field is present, it MUST be SM2-ENC-SM3.

  • If the "key_ops" field is present, it MUST include "encrypt" (3) when encrypting and "decrypt" (4) when decrypting. As SM2-ENC-SM3 is a key transport algorithm, the key wrap values "wrap key" and "unwrap key" do not apply.

9. JOSE Algorithms

This section defines the use of the SM algorithms with JSON Web Signature (JWS) [RFC7515], JSON Web Encryption (JWE) [RFC7516], and JSON Web Key (JWK) [RFC7517]. The cryptographic operations are those specified in the preceding sections; this section specifies the JOSE-specific inputs and encodings.

JOSE has no registry for hash algorithms and does not use CCM. Therefore, no JOSE counterparts are defined for SM3 and SM4-CCM. The "dir" algorithm of [RFC7518] can be used with SM4GCM, so no JOSE counterpart of direct+HKDF-SM3 is defined.

9.1. curveSM2 in JWK

Keys on curveSM2 use the "EC" key type defined in Section 6.2 of [RFC7518], with the "crv" parameter set to "curveSM2". The "x", "y", and "d" parameters contain the base64url encoding of the 32-octet values, as specified in Section 6.2 of [RFC7518].

The same curveSM2 key pair SHOULD NOT be used with both SM2-SM3 and SM2-ENC-SM3. A JWK for curveSM2 SHOULD contain the "alg" parameter to restrict the key to one algorithm.

9.2. SM2-SM3 for JWS

The "alg" value "SM2-SM3" denotes the SM2 signature algorithm on curveSM2 with SM3, as specified in Section 3.1, including the fixed distinguishing identifier of Section 3.1.1. The message M to be signed is the JWS Signing Input.

The JWS Signature is the 64-octet string I2OSP(r, 32) || I2OSP(s, 32), as for ECDSA in Section 3.4 of [RFC7518]. A verifier MUST reject a JWS Signature that is not 64 octets long.

When a JWK is used with SM2-SM3, the following checks are made:

  • The "kty" parameter MUST be "EC", and the "crv" parameter MUST be "curveSM2".

  • If the "alg" parameter is present, it MUST be "SM2-SM3".

  • If the "use" parameter is present, it MUST be "sig".

  • If the "key_ops" parameter is present, it MUST include "sign" when signing and "verify" when verifying.

9.3. HS-SM3 for JWS

The "alg" value "HS-SM3" denotes HMAC [RFC2104] with SM3. It is used as HS256 is used in Section 3.2 of [RFC7518], with SM3 in place of SHA-256: the HMAC is computed over the JWS Signing Input, and the 256-bit HMAC output is the JWS Signature.

As for HS256, a key of 256 bits or larger MUST be used, and the comparison of the computed HMAC value with the JWS Signature MUST be done in constant time. The key is represented as a JWK with the "kty" parameter "oct".

9.4. SM4GCM for JWE

The "enc" value "SM4GCM" denotes SM4 in Galois/Counter Mode [GCM]. It is used as A128GCM is used in Section 5.3 of [RFC7518], with SM4 in place of AES:

  • The CEK is 128 bits long.

  • The JWE Initialization Vector MUST be 96 bits long.

  • The JWE Authentication Tag is 128 bits long.

The Additional Authenticated Data is computed as specified in Section 5.1 of [RFC7516]. The parameters are the same as for SM4-GCM in Section 6.1.

9.5. SM2-ENC-SM3 for JWE

The "alg" value "SM2-ENC-SM3" denotes SM2 public key encryption on curveSM2 with SM3, as specified in Section 8.1. It is used for key encryption, as RSA-OAEP is used in Section 4.3 of [RFC7518]: the CEK is encrypted to the recipient's public key, and the JWE Encrypted Key is the SM2 ciphertext C1 || C3 || C2 in the format specified in Section 8.1. The recipient performs the decryption and the checks of Section 8.1.

When a JWK is used with SM2-ENC-SM3, the following checks are made:

  • The "kty" parameter MUST be "EC", and the "crv" parameter MUST be "curveSM2".

  • If the "alg" parameter is present, it MUST be "SM2-ENC-SM3".

  • If the "use" parameter is present, it MUST be "enc".

  • If the "key_ops" parameter is present, it MUST include "encrypt" or "wrapKey" when encrypting, and "decrypt" or "unwrapKey" when decrypting.

10. IANA Considerations

IANA is requested to register the values in this section in the registries of the "CBOR Object Signing and Encryption (COSE)" registry group [IANA.COSE] and of the "JSON Object Signing and Encryption (JOSE)" registry group [IANA.JOSE].

All requested COSE values are in the "Specification Required" ranges defined in [RFC9053] (see also [RFC8126]). The values in parentheses are suggestions only; the examples in Appendix A use them.

RFC Editor: Please replace TBD1 to TBD9 with the values assigned by IANA and remove this note.

10.1. COSE Elliptic Curves Registry

IANA is requested to register the following value in the "COSE Elliptic Curves" registry. In the "Reference" column, "Section N" refers to Section N of this document.

Table 10: COSE Elliptic Curves Registration
Name Value Key Type Description Change Controller Reference Recommended
curveSM2 TBD1 (260) EC2 SM2 elliptic curve curveSM2 (also known as sm2p256v1) IETF Section 2 No

10.2. COSE Algorithms Registry

IANA is requested to register the following values in the "COSE Algorithms" registry. For all entries, the "Change Controller" column contains "IETF", and the "Reference" column contains this document together with the section that defines the algorithm, as listed in Table 1. These two columns are omitted from the table below so that it fits the page width.

Table 11: COSE Algorithms Registrations
Name Value Description Capabilities Recommended
SM2-SM3 TBD2 (-269) SM2 signature using curveSM2 and SM3 [kty] No
SM3 TBD3 (-272) SM3 256-bit Hash [] No
HMAC-SM3 TBD4 (262) HMAC w/ SM3 [kty] No
SM4-GCM TBD5 (256) SM4-GCM mode w/ 128-bit key, 128-bit tag [kty] No
SM4-CCM-16-64-128 TBD6 (257) SM4-CCM mode 128-bit key, 64-bit tag, 13-byte nonce [kty] No
SM4-CCM-16-128-128 TBD7 (258) SM4-CCM mode 128-bit key, 128-bit tag, 13-byte nonce [kty] No
direct+HKDF-SM3 TBD8 (-271) Shared secret w/ HKDF and SM3 [kty] No
SM2-ENC-SM3 TBD9 (-270) SM2 public key encryption using curveSM2 and SM3 [kty] No

10.3. COSE Header Algorithm Parameters Registry

IANA is requested to update the following entries in the "COSE Header Algorithm Parameters" registry. The "Algorithm" column shows the algorithm to be added to the existing list of algorithms, and the "Reference" column shows the reference to be added. The other columns are unchanged.

Table 12: COSE Header Algorithm Parameters Updates
Name Algorithm Label Type Description Reference
salt direct+HKDF-SM3 -20 bstr Random salt This document
PartyU identity direct+HKDF-SM3 -21 bstr Party U identity information This document
PartyU nonce direct+HKDF-SM3 -22 bstr / int Party U provided nonce This document
PartyU other direct+HKDF-SM3 -23 bstr Party U other provided information This document
PartyV identity direct+HKDF-SM3 -24 bstr Party V identity information This document
PartyV nonce direct+HKDF-SM3 -25 bstr / int Party V provided nonce This document
PartyV other direct+HKDF-SM3 -26 bstr Party V other provided information This document

10.4. JSON Web Signature and Encryption Algorithms Registry

IANA is requested to register the following values in the "JSON Web Signature and Encryption Algorithms" registry. For all entries, the "JOSE Implementation Requirements" column contains "Optional", the "Change Controller" column contains "IETF", and the "Reference" column contains this document together with the section that defines the algorithm, as listed in Table 2.

Table 13: JSON Web Signature and Encryption Algorithms Registrations
Algorithm Name Algorithm Description Algorithm Usage Location(s) Algorithm Analysis Document(s)
SM2-SM3 SM2 signature using curveSM2 and SM3 alg [ISO-SM2], [ISO-SM3]
HS-SM3 HMAC using SM3 alg [ISO-SM3]
SM4GCM SM4 GCM using 128-bit key enc [ISO-SM4]
SM2-ENC-SM3 SM2 public key encryption using curveSM2 and SM3 alg [GBT.32918.4-2016]

10.5. JSON Web Key Elliptic Curve Registry

IANA is requested to register the following value in the "JSON Web Key Elliptic Curve" registry. In the "Reference" column, "Section N" refers to Section N of this document.

Table 14: JSON Web Key Elliptic Curve Registration
Curve Name Curve Description JOSE Implementation Requirements Change Controller Reference
curveSM2 SM2 elliptic curve curveSM2 (also known as sm2p256v1) Optional IETF Section 9.1

11. Security Considerations

The security considerations of [RFC9052] and [RFC9053] apply to the COSE algorithms, and those of [RFC7515], [RFC7516], and [RFC7518] apply to the JOSE algorithms. The security considerations of [RFC8998] apply to the use of the SM algorithms in general.

curveSM2, SM2, and SM3 are designed to provide approximately 128 bits of security. SM4 uses a 128-bit key.

SM2 signature generation and SM2 encryption require a fresh, secret, uniformly random value k for each operation, in both COSE and JOSE. For signatures, reuse or partial disclosure of k reveals the private key, as with ECDSA. For encryption, reuse of k with the same recipient key yields the same key stream and reveals the XOR of the encrypted CEKs, and disclosure of k reveals the CEK. The fixed values of k used in Appendix A and Appendix B are for reproducibility only and MUST NOT be used in practice. Implementations SHOULD protect the scalar multiplications against side-channel attacks.

The SM2 signature binds the distinguishing identifier and the public key through the value Z (Section 3.1.1). Because this document fixes the identifier, it provides no additional binding to a signer identity; applications that need such binding have to include the identity in the signed content or in protected header parameters.

An SM2 key pair SHOULD be used for a single algorithm only. Using the same key for both signature and encryption exposes it to cross-protocol attacks. For this purpose, the COSE and JOSE algorithms with the same name (SM2-SM3 and SM2-ENC-SM3) are the same algorithm.

Recipients of SM2-ENC-SM3 ciphertexts MUST validate that the received point C1 is on curveSM2 and is not the point at infinity, to prevent invalid-curve attacks. SM2 decryption failures SHOULD be indistinguishable to an attacker.

SM4 has a 128-bit block size. As with AES, the amount of data processed with a single key has to be limited. The limits that [I-D.irtf-cfrg-aead-limits] gives for AES-GCM and AES-CCM apply to SM4-GCM and SM4-CCM. Nonces MUST NOT be reused with the same key in any of the SM4 modes defined in this document; for SM4-GCM, reuse of a nonce destroys both confidentiality and integrity.

Truncated authentication tags (SM4-CCM with M = 64) offer a lower forgery resistance and SHOULD be used only in constrained environments where the additional overhead of full tags is unacceptable.

To avoid cross-protocol concerns, implementations MUST NOT use the same key with more than one of the SM4 modes.

The HMAC values of HMAC-SM3 and HS-SM3 MUST be compared in constant time; see also Section 11.5 of [RFC7516].

12. References

12.1. Normative References

[CCM]
Dworkin, M., "Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality", NIST Special Publication 800-38C, DOI 10.6028/NIST.SP.800-38C, , <https://doi.org/10.6028/NIST.SP.800-38C>.
[GBT.32918.1-2016]
Standardization Administration of the People's Republic of China, "Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 1: General", GB/T 32918.1-2016, .
[GBT.32918.4-2016]
Standardization Administration of the People's Republic of China, "Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 4: Public key encryption algorithm", GB/T 32918.4-2016, .
[GBT.32918.5-2017]
Standardization Administration of the People's Republic of China, "Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 5: Parameter definition", GB/T 32918.5-2017, .
[GCM]
Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, , <https://doi.org/10.6028/NIST.SP.800-38D>.
[GMT.0006-2012]
State Cryptography Administration, "Cryptographic application identifier criterion specification", GM/T 0006-2012, .
[GMT.0009-2012]
State Cryptography Administration, "SM2 cryptography algorithm application specification", GM/T 0009-2012, .
[ISO-SM2]
International Organization for Standardization, "IT Security techniques -- Digital signatures with appendix -- Part 3: Discrete logarithm based mechanisms", ISO/IEC 14888-3:2018, , <https://www.iso.org/standard/76382.html>.
[ISO-SM3]
International Organization for Standardization, "IT Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions", ISO/IEC 10118-3:2018, , <https://www.iso.org/standard/67116.html>.
[ISO-SM4]
International Organization for Standardization, "Information technology -- Security techniques -- Encryption algorithms -- Part 3: Block ciphers -- Amendment 1: SM4", ISO/IEC 18033-3:2010/Amd 1:2021, , <https://www.iso.org/standard/81564.html>.
[RFC2104]
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, , <https://www.rfc-editor.org/rfc/rfc2104>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5869]
Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, , <https://www.rfc-editor.org/rfc/rfc5869>.
[RFC7515]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7516]
Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, , <https://www.rfc-editor.org/rfc/rfc7516>.
[RFC7517]
Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, , <https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7518]
Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, , <https://www.rfc-editor.org/rfc/rfc7518>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9052]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9053]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, , <https://www.rfc-editor.org/rfc/rfc9053>.
[RFC9054]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Hash Algorithms", RFC 9054, DOI 10.17487/RFC9054, , <https://www.rfc-editor.org/rfc/rfc9054>.
[RFC9459]
Housley, R. and H. Tschofenig, "CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC", RFC 9459, DOI 10.17487/RFC9459, , <https://www.rfc-editor.org/rfc/rfc9459>.
[RFC9864]
Jones, M.B. and O. Steele, "Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9864, DOI 10.17487/RFC9864, , <https://www.rfc-editor.org/rfc/rfc9864>.

12.2. Informative References

[CRYPTO-LAW]
Standing Committee of the National People's Congress, "Cryptography Law of the People's Republic of China", .
[GBT.32905-2016]
Standardization Administration of the People's Republic of China, "Information security technology --- SM3 cryptographic hash algorithm", GB/T 32905-2016, .
[GBT.32907-2016]
Standardization Administration of the People's Republic of China, "Information security technology --- SM4 block cipher algorithm", GB/T 32907-2016, .
[GBT.32918.2-2016]
Standardization Administration of the People's Republic of China, "Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 2: Digital signature algorithm", GB/T 32918.2-2016, .
[GBT.38636-2020]
Standardization Administration of the People's Republic of China, "Information security technology --- Transport layer cryptography protocol (TLCP)", GB/T 38636-2020, .
[GBT.39786-2021]
State Administration for Market Regulation and Standardization Administration of the People's Republic of China, "Information security technology --- Baseline for information system cryptography application", GB/T 39786-2021, .
[I-D.ietf-suit-manifest]
Moran, B., Tschofenig, H., Birkholz, H., Zandberg, K., and O. Rønningstad, "A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest", Work in Progress, Internet-Draft, draft-ietf-suit-manifest-37, , <https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-37>.
[I-D.irtf-cfrg-aead-limits]
Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on AEAD Algorithms", Work in Progress, Internet-Draft, draft-irtf-cfrg-aead-limits-13, , <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-13>.
[IANA.COSE]
IANA, "CBOR Object Signing and Encryption (COSE)", n.d., <https://www.iana.org/assignments/cose>.
[IANA.JOSE]
IANA, "JSON Object Signing and Encryption (JOSE)", n.d., <https://www.iana.org/assignments/jose>.
[RFC3610]
Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, , <https://www.rfc-editor.org/rfc/rfc3610>.
[RFC7519]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8392]
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, , <https://www.rfc-editor.org/rfc/rfc8392>.
[RFC8613]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, , <https://www.rfc-editor.org/rfc/rfc8613>.
[RFC8812]
Jones, M., "CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms", RFC 8812, DOI 10.17487/RFC8812, , <https://www.rfc-editor.org/rfc/rfc8812>.
[RFC8998]
Yang, P., "ShangMi (SM) Cipher Suites for TLS 1.3", RFC 8998, DOI 10.17487/RFC8998, , <https://www.rfc-editor.org/rfc/rfc8998>.
[RFC9068]
Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, , <https://www.rfc-editor.org/rfc/rfc9068>.
[RFC9124]
Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices", RFC 9124, DOI 10.17487/RFC9124, , <https://www.rfc-editor.org/rfc/rfc9124>.
[RFC9203]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9203, DOI 10.17487/RFC9203, , <https://www.rfc-editor.org/rfc/rfc9203>.
[RFC9360]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, DOI 10.17487/RFC9360, , <https://www.rfc-editor.org/rfc/rfc9360>.
[RFC9528]
Selander, G., Preuß Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, , <https://www.rfc-editor.org/rfc/rfc9528>.
[RFC9711]
Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, , <https://www.rfc-editor.org/rfc/rfc9711>.
[RFC9861]
Viguier, B., Wong, D., Ed., Van Assche, G., Ed., Dang, Q., Ed., and J. Daemen, Ed., "KangarooTwelve and TurboSHAKE", RFC 9861, DOI 10.17487/RFC9861, , <https://www.rfc-editor.org/rfc/rfc9861>.
[RFC9964]
Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, , <https://www.rfc-editor.org/rfc/rfc9964>.
[VEHICLE-CRYPTO]
Ministry of Industry and Information Technology of the People's Republic of China and State Cryptography Administration, "Technical requirements for vehicle cryptography application (draft for comments)", GB XXXXX-XXXX, , <https://std.samr.gov.cn/dcpspTools/gbPlan/download?path=%2Fzxd%2F2023002617%2F20_%E6%A0%87%E5%87%86%E8%B5%B7%E8%8D%89%2F20_WD_2023002617_%E6%B1%BD%E8%BD%A6%E5%AF%86%E7%A0%81%E5%BA%94%E7%94%A8%E6%8A%80%E6%9C%AF%E8%A6%81%E6%B1%82.pdf>.

Appendix A. COSE Examples

This appendix gives examples of COSE objects using the algorithms of this document. The examples are shown in CBOR diagnostic notation followed by the hexadecimal encoding. They use the values suggested to IANA; they will be regenerated if IANA assigns different values.

All examples use the payload "This is the content." (20 octets) and an empty external_aad. The random values, such as the k used in SM2, were fixed so that the examples can be reproduced.

The examples were generated with an implementation independent of OpenSSL, except for SM3. The SM2 signature, SM2 decryption, and HMAC-SM3 results were cross-checked with OpenSSL 4.1. The SM4-GCM and SM4-CCM implementations reproduce the test vectors in Appendix A of [RFC8998].

A.1. Keys

The SM2 signing key:

{
  1 / kty /: 2 / EC2 /,
  2 / kid /: h'736d322d7369676e406578616d706c652e636f6d',
  3 / alg /: -269 / SM2-SM3 /,
  -1 / crv /: 260 / curveSM2 /,
  -2 / x /: h'9e4781ddf2df6f41e62cd26d6f43708a76f928f46141ca0bf0
    a7371884806caf',
  -3 / y /: h'db11335b8f7af16cf709e57e66b750195b6957a5c5b8370055
    4594c48a6bd3b2',
  -4 / d /: h'73ff4d82f7c10fe1408877ad2bfbce0d611fb1fa8ea5080441
    060c9c50550ca2'
}

The SM2 encryption key:

{
  1 / kty /: 2 / EC2 /,
  2 / kid /: h'736d322d656e63406578616d706c652e636f6d',
  3 / alg /: -270 / SM2-ENC-SM3 /,
  -1 / crv /: 260 / curveSM2 /,
  -2 / x /: h'c29c3a6334139ef9a9cc12741764d8115f55f9f23720ed21c4
    ed63166b91d1aa',
  -3 / y /: h'83144e0d0612c6cd1d8f73c32583a63a0346ab8a66f2a0dbe7
    2e603db274733c',
  -4 / d /: h'8160d94d63f3eb30a2bb89dd02e4b29713667f3a2696d347d9
    86a9f2d3a6f7df'
}

The symmetric key used for SM4:

{
  1 / kty /: 4 / Symmetric /,
  2 / kid /: h'6f75722d73656372657432',
  -1 / k /: h'849b57219dae48de646d07dbb533566e'
}

The symmetric key used for HMAC-SM3 and direct+HKDF-SM3:

{
  1 / kty /: 4 / Symmetric /,
  2 / kid /: h'6f75722d736563726574',
  -1 / k /: h'849b57219dae48de646d07dbb533566e976686457c1491be3a
    76dcea6c427188'
}

A.2. SM2-SM3 Signature

The encoded Sig_structure (ToBeSigned):

846a5369676e61747572653145a10139010c4054546869732069732074686520
636f6e74656e742e

The COSE_Sign1 object:

18(
  [
    h'a10139010c' / {1: -269} /,
    {
      4 / kid /: h'736d322d7369676e406578616d706c652e636f6d'
    },
    h'546869732069732074686520636f6e74656e742e',
    h'39192506a55604477fdaac0983fd888d06bbe09a2cbce3d7
      0cf20a4cd32e5fb2d1a12c5829746b162eac73afc7cf0f81
      e67117901b4d9bc36292d71f4f56f083'
  ]
)

d28445a10139010ca10454736d322d7369676e406578616d706c652e636f6d54
546869732069732074686520636f6e74656e742e584039192506a55604477fda
ac0983fd888d06bbe09a2cbce3d70cf20a4cd32e5fb2d1a12c5829746b162eac
73afc7cf0f81e67117901b4d9bc36292d71f4f56f083

A.3. HMAC-SM3

The encoded MAC_structure:

84644d41433045a1011901064054546869732069732074686520636f6e74656e
742e

The COSE_Mac0 object:

17(
  [
    h'a101190106' / {1: 262} /,
    {
      4 / kid /: h'6f75722d736563726574'
    },
    h'546869732069732074686520636f6e74656e742e',
    h'94811cb0028f19171d2e1776c6e3ac896c79f9d21ec8478d
      545ddb11a45fc5bd'
  ]
)

d18445a101190106a1044a6f75722d7365637265745454686973206973207468
6520636f6e74656e742e582094811cb0028f19171d2e1776c6e3ac896c79f9d2
1ec8478d545ddb11a45fc5bd

A.4. SM4-GCM

The encoded Enc_structure:

8368456e63727970743045a10119010040

The COSE_Encrypt0 object:

16(
  [
    h'a101190100' / {1: 256} /,
    {
      4 / kid /: h'6f75722d73656372657432',
      5 / iv /: h'02d1f7e6f26c43d4868d87ce'
    },
    h'db19f211e5cf306ecb979325474b357b7a3fad1077d4eb39
      0a56b06a879685bc04c74ce5'
  ]
)

d08345a101190100a2044b6f75722d73656372657432054c02d1f7e6f26c43d4
868d87ce5824db19f211e5cf306ecb979325474b357b7a3fad1077d4eb390a56
b06a879685bc04c74ce5

A.5. SM4-CCM-16-64-128 

16(
  [
    h'a101190101' / {1: 257} /,
    {
      4 / kid /: h'6f75722d73656372657432',
      5 / iv /: h'89f52f65a1c580933b5261a72f'
    },
    h'dc9ae5a858a8da807a0afcd8f34533b032fe874b67e2cc98
      01431a35'
  ]
)

d08345a101190101a2044b6f75722d73656372657432054d89f52f65a1c58093
3b5261a72f581cdc9ae5a858a8da807a0afcd8f34533b032fe874b67e2cc9801
431a35

A.6. SM4-CCM-16-128-128 

16(
  [
    h'a101190102' / {1: 258} /,
    {
      4 / kid /: h'6f75722d73656372657432',
      5 / iv /: h'89f52f65a1c580933b5261a72f'
    },
    h'dc9ae5a858a8da807a0afcd8f34533b032fe874b6eaf7d90
      da38798c05dd29e2e5501d55'
  ]
)

d08345a101190102a2044b6f75722d73656372657432054d89f52f65a1c58093
3b5261a72f5824dc9ae5a858a8da807a0afcd8f34533b032fe874b6eaf7d90da
38798c05dd29e2e5501d55

A.7. SM2-ENC-SM3 with SM4-GCM

The CEK:

2b1d4f5e7a9c0b3d6e8f1a2c4b5d7e90

The COSE_Encrypt object. The CEK is encrypted for the SM2 encryption key shown above:

96(
  [
    h'a101190100' / {1: 256} /,
    {
      5 / iv /: h'02d1f7e6f26c43d4868d87ce'
    },
    h'1758357c02c3bc27bbea239b6b7480cbfb0e1c6d3f1a8dd2
      9fe3121d5d02413045e18338',
    [
      [
        h'',
        {
          1 / alg /: -270 / SM2-ENC-SM3 /,
          4 / kid /: h'736d322d656e63406578616d706c652e636f6d'
        },
        h'04656f6548474c10f4d98140c34f02a8b91acfad36e2
          bf8071ae547dfe4c5ef1910dcef4c72f3c6ae8a68b78
          d4fbed56662c6e3ccb8967d3720f351772ec01948614
          4e7770b98cd5f2bb6337fd11b8735237b6a98219f016
          2f6b1fee1ee27557d9d862d7c0ab65776a500d81cdf8
          41c585'
      ]
    ]
  ]
)

d8608445a101190100a1054c02d1f7e6f26c43d4868d87ce58241758357c02c3
bc27bbea239b6b7480cbfb0e1c6d3f1a8dd29fe3121d5d02413045e183388183
40a20139010d0453736d322d656e63406578616d706c652e636f6d587104656f
6548474c10f4d98140c34f02a8b91acfad36e2bf8071ae547dfe4c5ef1910dce
f4c72f3c6ae8a68b78d4fbed56662c6e3ccb8967d3720f351772ec019486144e
7770b98cd5f2bb6337fd11b8735237b6a98219f0162f6b1fee1ee27557d9d862
d7c0ab65776a500d81cdf841c585

A.8. direct+HKDF-SM3 with SM4-GCM

The encoded COSE_KDF_Context:

8419010083f6f6f683f6f6f682188045a10139010e

The derived CEK:

98c5099beb07c7a6bdce325c89be85b5

The COSE_Encrypt object:

96(
  [
    h'a101190100' / {1: 256} /,
    {
      5 / iv /: h'02d1f7e6f26c43d4868d87ce'
    },
    h'902b98d6078acea3ce5ade7bdc437e63a1df43ea59669635
      c23543af16cd2e6dc91f72fe',
    [
      [
        h'a10139010e' / {1: -271} /,
        {
          4 / kid /: h'6f75722d736563726574',
          -20 / salt /: h'61616262636364646565666667676868'
        },
        h''
      ]
    ]
  ]
)

d8608445a101190100a1054c02d1f7e6f26c43d4868d87ce5824902b98d6078a
cea3ce5ade7bdc437e63a1df43ea59669635c23543af16cd2e6dc91f72fe8183
45a10139010ea2044a6f75722d73656372657433506161626263636464656566
666767686840

A.9. SM3 Hash

The SM3 hash of the payload, as a COSE_CertHash [RFC9360] array [hashAlg, hashValue]:

[
  -272 / SM3 /,
  h'7f093ad3f67a1d16dcf1397f1b419edb85f693196072712a9a
    5fef65adfb903d'
]

Appendix B. JOSE Examples

This appendix gives examples of JOSE objects using the algorithms of this document. All examples use the payload "This is the content." (20 octets) and the JWS and JWE Compact Serializations. Line breaks within the serializations are for display purposes only. As in Appendix A, the random values were fixed so that the examples can be reproduced; each SM2 operation uses a different k.

The SM2-SM3 signature, SM2 decryption, and HS-SM3 results were cross-checked with OpenSSL 4.1.

B.1. Keys

The SM2 signing key (the same key pair as in Appendix A.1):

{
  "kty": "EC",
  "crv": "curveSM2",
  "kid": "sm2-sign@example.com",
  "alg": "SM2-SM3",
  "x": "nkeB3fLfb0HmLNJtb0Nwinb5KPRhQcoL8Kc3GISAbK8",
  "y": "2xEzW4968Wz3CeV-ZrdQGVtpV6XFuDcAVUWUxIpr07I",
  "d": "c_9NgvfBD-FAiHetK_vODWEfsfqOpQgEQQYMnFBVDKI"
}

The SM2 encryption key (the same key pair as in Appendix A.1):

{
  "kty": "EC",
  "crv": "curveSM2",
  "kid": "sm2-enc@example.com",
  "alg": "SM2-ENC-SM3",
  "x": "wpw6YzQTnvmpzBJ0F2TYEV9V-fI3IO0hxO1jFmuR0ao",
  "y": "gxRODQYSxs0dj3PDJYOmOgNGq4pm8qDb5y5gPbJ0czw",
  "d": "gWDZTWPz6zCiu4ndAuSylxNmfzomltNH2Yap8tOm998"
}

The symmetric key used for HS-SM3:

{
  "kty": "oct",
  "kid": "our-secret",
  "alg": "HS-SM3",
  "k": "hJtXIZ2uSN5kbQfbtTNWbpdmhkV8FJG-Onbc6mxCcYg"
}

B.2. SM2-SM3

The JWS Protected Header:

{"alg":"SM2-SM3","kid":"sm2-sign@example.com"}

The JWS:

eyJhbGciOiJTTTItU00zIiwia2lkIjoic20yLXNpZ25AZXhhbXBsZS5jb20ifQ.V
GhpcyBpcyB0aGUgY29udGVudC4.7OLwFhhRIzWXCZCvz_2Nsbyl2tX-iZ6GQ9xXs
sKhQjNWZlABpscWjDz3uvNP6oOD6FLSgJcQIG9LcwLhmvV2OA

B.3. HS-SM3

The JWS Protected Header:

{"alg":"HS-SM3","kid":"our-secret"}

The JWS:

eyJhbGciOiJIUy1TTTMiLCJraWQiOiJvdXItc2VjcmV0In0.VGhpcyBpcyB0aGUg
Y29udGVudC4.U-o8leTbGIzMtiDT0YeLIeI2v2miqhcDWZ2fCZ2LDRE

B.4. SM2-ENC-SM3 with SM4GCM

The JWE Protected Header:

{"alg":"SM2-ENC-SM3","enc":"SM4GCM","kid":"sm2-enc@example.com"}

The CEK:

5a2c0b8e1f3d4c6a7b9e8d0f2a4c6e81

The JWE:

eyJhbGciOiJTTTItRU5DLVNNMyIsImVuYyI6IlNNNEdDTSIsImtpZCI6InNtMi1l
bmNAZXhhbXBsZS5jb20ifQ.BPGdA0qNpMxZMfv1Ohr6NliMbI7d0rL_S8wlxhvBa
7Bwxg7C2HqqoyhahlwI_30qw75nKJvcPZa8EnKeXT-AFDgvZvpiZbdHgFpVMfPvJ
NsGuWpJx_0F1-zmycCCTbB9vXjdUFGRIHjGKuCnIglKZ4M.AtH35vJsQ9SGjYfO.
BTjaxXhDAofvkn5J59km0BVwIk0.u0ocY66HLxGoLt798YyI9A

Acknowledgments

TODO

Authors' Addresses

Lijun Liao
NIO Inc.
China
Guilin Wang
Huawei Int. Pte Ltd
Singapore
Heng Cai
Alibaba Cloud
China
Xinyuan Zhai
TrustAsia
China