]> NIO Inc.

China lijun.liao@nio.io

Huawei Int. Pte Ltd

Singapore wang.guilin@huawei.com

Alibaba Cloud

China caiheng.cai@alibaba-inc.com

TrustAsia

China edwin.zhai@trustasia.com

Security CBOR Object Signing and Encryption JOSE COSE SM2 SM3 SM4 ShangMi curveSM2 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.

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 , the hash function SM3 , and the block cipher SM4 . specifies how these algorithms are used in TLS 1.3. CBOR Object Signing and Encryption (COSE) uses algorithm identifiers and elliptic curve identifiers registered in the "COSE Algorithms" and "COSE Elliptic Curves" registries . No identifiers for the ShangMi algorithms have been registered so far. The same holds for JSON Object Signing and Encryption (JOSE) and its "JSON Web Signature and Encryption Algorithms" and "JSON Web Key Elliptic Curve" registries . This document fills that gap: it defines how the SM algorithms are used with COSE and with JOSE and requests the corresponding registrations. Like and , it covers both COSE and JOSE in one document. This document follows the patterns established by earlier COSE algorithm documents: for signature, MAC, content encryption, and key distribution algorithms; and for hash functions; and for fully-specified algorithm identifiers. The COSE algorithms defined in this document are: Name Section Purpose SM2-SM3 Signature SM3 Hash HMAC-SM3 MAC SM4-GCM Content encryption, AEAD SM4-CCM-16-64-128 Content encryption, AEAD SM4-CCM-16-128-128 Content encryption, AEAD direct+HKDF-SM3 Key derivation SM2-ENC-SM3 Key transport The JOSE algorithms defined in this document are: Name Usage Section Purpose SM2-SM3 alg JWS signature HS-SM3 alg JWS MAC SM4GCM enc JWE content encryption SM2-ENC-SM3 alg JWE key encryption In addition, this document registers the elliptic curve curveSM2 for both COSE () and JOSE (). The following algorithms are intentionally not defined in this document: HMAC-SM3 with a truncated tag, the counterpart of HMAC 256/64 in : no use in COSE is known, and the constrained protocols OSCORE and EDHOC do not use COSE MAC algorithms. SM4 in CTR and CBC mode, the counterparts of AES-CTR and AES-CBC in : these modes provide no integrity protection and are only suitable for special cases in which integrity is provided by another mechanism. SM4 in CBC mode combined with HMAC-SM3 for JWE, the counterpart of A128CBC-HS256 in : this combination is not specified anywhere else, and SM4GCM covers the use case. SM4-CCM variants other than those with L = 16 (). These algorithms can be specified in a separate document if a need arises.

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 establishes the framework for commercial cryptography, and national standards such as 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" , 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 , which implement the SUIT information model 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 , with keys established by EDHOC ; carrying authorization for diagnostic and remote control access in CBOR Web Tokens (CWTs) ; and attesting the state of ECUs with Entity Attestation Tokens . 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 ; 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 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.

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 when, and only when, they appear in all capitals, as shown here.

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 and . 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 and . COSE key operation values are given by their name in Table 5 of , 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.

The Elliptic Curve curveSM2 The elliptic curve curveSM2 is the 256-bit prime field Weierstrass curve y^2 = x^3 + ax + b defined in and . It is the curve that 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 . Its parameters are:

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.

COSE Key Representation Keys on curveSM2 use the "EC2" key type defined in Section 7.1 of . 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 . 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.

Signature Algorithm

SM2 with SM3 This section defines the use of the SM2 digital signature algorithm on curveSM2 with the SM3 hash function. The algorithm identifier is fully specified in the sense of : it determines both the curve and the hash function. Name Value Description SM2-SM3 TBD2 SM2 signature using curveSM2 and SM3

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:

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 , 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 . 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 require the "ctx" parameter to be the empty string, and Ed448 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 ().

Signing and Verification Signing a COSE object with SM2-SM3 uses the procedure in Section 4.4 of . The message M to be signed is the encoded Sig_structure (ToBeSigned). The signer: computes e = SM3(Z || M), interpreted as a big-endian integer; generates a fresh random integer k in [1, n-1] and computes (x1, y1) = [k]G; computes r = (e + x1) mod n. If r = 0 or r + k = n, it returns to step 2; 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 . 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).

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.

Hash Algorithm This section registers the SM3 hash function for use with COSE, for example in the hash structures of or in the COSE_CertHash structure of . SM3 produces a 256-bit hash value. Name Value Description SM3 TBD3 SM3 256-bit Hash SM3 does not take a key. As specified for the hash functions in , the COSE capabilities array for SM3 is therefore empty (see Section 8 of ).

Message Authentication Code Algorithm This section defines the use of HMAC with the SM3 hash function. HMAC-SM3 is used as described for HMAC in Section 3.1 of , with SM3 in place of the SHA-2 hash function. Name Value Description HMAC-SM3 TBD4 HMAC w/ SM3 As for HMAC with SHA-256 in Section 3.1 of , 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: The "kty" field MUST be present and MUST be "Symmetric". If the "alg" field is present, it MUST match the algorithm being used. If the "key_ops" field is present, it MUST include "MAC create" (9) when creating a MAC and "MAC verify" (10) when verifying a MAC.

Content Encryption Algorithms SM4 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.

SM4-GCM SM4 in Galois/Counter Mode is used as described for AES-GCM in Section 4.1 of , 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 . The authentication tag is 128 bits. The tag is appended to the ciphertext. 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 , whose test vectors therefore also apply to SM4-GCM.

SM4-CCM SM4 in Counter with CBC-MAC mode is used as described for AES-CCM in Section 4.2 of . 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 , where K is the key size in bits. 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 , 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 and EDHOC ; 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 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.

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.

Key Derivation Algorithm This section defines the use of HKDF 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 , with HMAC-SM3 in place of HMAC-SHA-256. 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 . The salt is taken from the "salt" header parameter if present; otherwise, a string of 32 zero octets is used, as specified in . The "PartyU" and "PartyV" header parameters of Section 5.2 of MAY be used. The key requirements are those of Section 6.1.2 of . 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 ; Section 3.2.1 of ).

Content Key Distribution Methods

SM2 Public Key Encryption with SM3 This section defines the use of the SM2 public key encryption algorithm on curveSM2 as a key transport method (Section 8.5.3 of ), 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). Name Value Description SM2-ENC-SM3 TBD9 SM2 public key encryption using curveSM2 and SM3

Encryption Given the recipient's public key PB on curveSM2 and the CEK of klen octets, the sender: generates a fresh random integer k in [1, n-1]; computes C1 = [k]G = (x1, y1) and (x2, y2) = [k]PB; computes t = KDF(I2OSP(x2, 32) || I2OSP(y2, 32), klen). If t consists only of zero octets, it returns to step 1; computes C2 = CEK XOR t; computes C3 = SM3(I2OSP(x2, 32) || CEK || I2OSP(y2, 32)). KDF is the key derivation function of 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

where C1 is encoded as an uncompressed point , 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 ; the order C1 || C2 || C3 used by some early implementations MUST NOT be used.

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.

Header Parameters and Key Requirements As for all key transport algorithms (Section 8.5.3 of ), 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.

JOSE Algorithms This section defines the use of the SM algorithms with JSON Web Signature (JWS) , JSON Web Encryption (JWE) , and JSON Web Key (JWK) . 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 can be used with SM4GCM, so no JOSE counterpart of direct+HKDF-SM3 is defined.

curveSM2 in JWK Keys on curveSM2 use the "EC" key type defined in Section 6.2 of , 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 . 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.

SM2-SM3 for JWS The "alg" value "SM2-SM3" denotes the SM2 signature algorithm on curveSM2 with SM3, as specified in , including the fixed distinguishing identifier of . 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 . 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.

HS-SM3 for JWS The "alg" value "HS-SM3" denotes HMAC with SM3. It is used as HS256 is used in Section 3.2 of , 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".

SM4GCM for JWE The "enc" value "SM4GCM" denotes SM4 in Galois/Counter Mode . It is used as A128GCM is used in Section 5.3 of , 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 . The parameters are the same as for SM4-GCM in .

SM2-ENC-SM3 for JWE The "alg" value "SM2-ENC-SM3" denotes SM2 public key encryption on curveSM2 with SM3, as specified in . It is used for key encryption, as RSA-OAEP is used in Section 4.3 of : 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 . The recipient performs the decryption and the checks of . 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.

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 and of the "JSON Object Signing and Encryption (JOSE)" registry group . All requested COSE values are in the "Specification Required" ranges defined in (see also ). The values in parentheses are suggestions only; the examples in use them. RFC Editor: Please replace TBD1 to TBD9 with the values assigned by IANA and remove this note.

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. Name Value Key Type Description Change Controller Reference Recommended curveSM2 TBD1 (260) EC2 SM2 elliptic curve curveSM2 (also known as sm2p256v1) IETF No

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 . These two columns are omitted from the table below so that it fits the page width. 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

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

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 . Algorithm Name Algorithm Description Algorithm Usage Location(s) Algorithm Analysis Document(s) SM2-SM3 SM2 signature using curveSM2 and SM3 alg , HS-SM3 HMAC using SM3 alg SM4GCM SM4 GCM using 128-bit key enc SM2-ENC-SM3 SM2 public key encryption using curveSM2 and SM3 alg

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. Curve Name Curve Description JOSE Implementation Requirements Change Controller Reference curveSM2 SM2 elliptic curve curveSM2 (also known as sm2p256v1) Optional IETF

Security Considerations The security considerations of and apply to the COSE algorithms, and those of , , and apply to the JOSE algorithms. The security considerations of 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 and 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 (). 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 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 .

This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. 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 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. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers. The Concise Binary Object Representation (CBOR) data format is designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) is specified in RFC 9052 to provide basic security services using the CBOR data format. This document specifies the conventions for using AES-CTR and AES-CBC as content encryption algorithms with COSE. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. International Organization for Standardization International Organization for Standardization International Organization for Standardization Standardization Administration of the People's Republic of China Standardization Administration of the People's Republic of China Standardization Administration of the People's Republic of China State Cryptography Administration State Cryptography Administration 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. Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES). The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. Arm Limited University of Applied Sciences Bonn-Rhein-Sieg Fraunhofer SIT Inria Nordic Semiconductor This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an Internet of Things (IoT) device), where to find the code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. Vulnerabilities with Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism that is also suitable for constrained devices. Ensuring that devices function and remain secure over their service lifetime requires such an update mechanism to fix vulnerabilities, update configuration settings, and add new functionality. One component of such a firmware update is a concise and machine-processable metadata document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3. The use of these algorithms with TLS 1.3 is not endorsed by the IETF. The SM algorithms are becoming mandatory in China, so this document provides a description of how to use the SM algorithms with TLS 1.3 and specifies a profile of TLS 1.3 so that implementers can produce interworking implementations. This document defines four eXtendable-Output Functions (XOFs), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128, and KT256. All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way. This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in NIST FIPS 202 and is meant to serve as a stable reference and an implementation guide. IBM Research Europe - Zurich Mozilla Cloudflare An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Standardization Administration of the People's Republic of China Standardization Administration of the People's Republic of China Standardization Administration of the People's Republic of China Ministry of Industry and Information Technology of the People's Republic of China and State Cryptography Administration Standing Committee of the National People's Congress State Administration for Market Regulation and Standardization Administration of the People's Republic of China Standardization Administration of the People's Republic of China IANA IANA

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 .

Keys The SM2 signing key:

The SM2 encryption key:

The symmetric key used for SM4:

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

SM2-SM3 Signature The encoded Sig_structure (ToBeSigned):

The COSE_Sign1 object:

HMAC-SM3 The encoded MAC_structure:

The COSE_Mac0 object:

SM4-GCM The encoded Enc_structure:

The COSE_Encrypt0 object:

SM4-CCM-16-64-128

SM4-CCM-16-128-128

SM2-ENC-SM3 with SM4-GCM The CEK:

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

direct+HKDF-SM3 with SM4-GCM The encoded COSE_KDF_Context:

The derived CEK:

The COSE_Encrypt object:

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

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

Keys The SM2 signing key (the same key pair as in ):

The SM2 encryption key (the same key pair as in ):

The symmetric key used for HS-SM3:

SM2-SM3 The JWS Protected Header:

The JWS:

HS-SM3 The JWS Protected Header:

The JWS:

SM2-ENC-SM3 with SM4GCM The JWE Protected Header:

The CEK:

The JWE:

Acknowledgments TODO