]> Independent

dajiaji@gmail.com

Security CBOR Object Signing and Encryption This document defines an additional key parameter and a new key type for CBOR Object Signing and Encryption (COSE) Key and JSON Web Key (JWK) to represent a Key Encapsulated Mechanism (KEM) key and its associated information for Hybrid Public Key Encryption (HPKE). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the CBOR Object Signing and Encryption Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Hybrid Public Key Encryption (HPKE) , published by the Internet Research Task Force (IRTF), has already been adopted in several communication protocol specifications such as TLS Encrypted Client Hello (ECH), Oblivious DNS over HTTPS (ODoH) and Oblivious HTTP (OHTTP). HPKE itself is communication protocol independent and can be widely used as a standard scheme for public key based end-to-end encryption in various applications, not only in communication protocols. In HPKE, the sender of a ciphertext needs to know in advance not only the recipient public key, but also the HPKE mode, the KEM associated with the key, and the set of supported KDF and AEAD algorithms. The data structure of this information (hereafter referred to as HPKE key configuration information) is defined in each communication protocol specification that uses HPKE. For example, the ECH defines it as a structure called HpkeKeyConfig. When using HPKE in an application, it is necessary to define the data structure corresponding to the HpkeKeyConfig and how the information is transferred from the recipient to the sender. If the data structure and the publication method for the HPKE key configuration information were standardized, it would be easier to use HPKE in applications. This document defines how to represent a KEM key for HPKE and the HPKE key configuration information in JSON Web Key (JWK) and COSE_Key defined in CBOR Object Signing and Encryption (COSE) Structures and Process . Specifically, this document defines (1) a common key parameter for defining the HPKE key configuration information in existing key types that can be used for key derivation and (2) a generic key type for HPKE that can also be used to represent post-quantum KEM keys to be specified in the future. By using the generic key type for HPKE, all KEM keys registered in the IANA HPKE registry can be represented in JWK and COSE_Key without the need to define cryptographic algorithm-specific key types and parameters such as for EC or RSA as defined in and . The ability to include HPKE-related information in JWK, which is widely used not only as the public key representation but also as the key publication method (via the JWK Set endpoint) at the application layer, and its binary representation, COSE_Key, will facilitate the use of HPKE in a wide variety of web applications and communication systems for constrained devices.

Conventions and Definitions 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.

Common Key Parameter for HPKE Key Configuration The HPKE key configuration information is defined as a common key parameter of JWK and COSE_Key. The parameter can be specified in the key that can be used for key derivation. In addition, the handling of existing key parameters is also defined.

JWK Parameter

"hkc" (HPKE Key Configuration) Parameter The "hkc" (KPKE key configuration) parameter identifies the KEM for the recipient key and the set of KDF and AEAD algorithms supported by the recipient. A JWK used for HPKE KEM MUST have this parameter. It MUST contain the object consisting of the following three attributes.

• "kem": The HPKE KEM identifier, which is a two-byte value registered in the IANA HPKE registry.
• "kdfs": The array of the HPKE KDF identifiers supported by the recipient. The KDF identifier is also a two-byte value registered in the IANA HPKE registry.
• "aeads": The array of the HPKE AEAD identifiers supported by the recipient. The AEAD identifier is also a two-byte value registered in the IANA HPKE registry.

The "hkc" parameter can be used with existing "EC" and "OKP" keys and the keys for future post-quantum KEMs.

Restrictions on the Use of Existing Key Parameters The restrictions on the use of existing common key parameters in a JWK for HPKE KEM are as follows:

• "alg": The parameter MUST be present and contains one of the following values:
  • "HPKE-v1-Base"
  • "HPKE-v1-PSK"
  • "HPKE-v1-Auth"
  • "HPKE-v1-AuthPSK"
• "use": The parameter SHOULD NOT be specified. If specified, it MUST be "enc".
• "key_ops": The parameter SHOULD NOT be specified. If specified, it MUST include "deriveKey" and/or "deriveBits".
• etc.

COSE Key Common Parameter

hkc (HPKE Key Configuration) Parameter The HPKE key configuration parameter for COSE_Key is defined as follows:

• hkc (HPKE Key Configuration): The parameter MUST contain an array structure named HPKE_Key_Configuration, which contains the same information as "hkc" in JWK above. The CDDL grammar describing the HPKE_Key_Configuration structure is:

HPKE Key Configuration Parameters

Name	CBOR Type	Value Registry	Description
kem	uint	HPKE KEM Identifiers	The KEM identifier bound to the key
kdfs	uint / [+uint]	HPKE KDF Identifiers	The KDF identifiers supported by the recipient
aeads	uint / [+uint]	HPKE AEAD Identifiers	The AEAD identifiers supported by the recipient

The hkc parameter can be used with existing OKP and EC2 keys and the keys for future post-quantum KEMs.

Restrictions on the Use of Existing Key Parameters The restrictions on the use of existing common key parameters in a COSE_Key for the HPKE KEM are as follows:

• alg(3): The parameter MUST be present and contains one of the following values:
  • HPKE-v1-Base (T.B.D.)
  • HPKE-v1-PSK (T.B.D.)
  • HPKE-v1-Auth (T.B.D.)
  • HPKE-v1-AuthPSK (T.B.D.)
• key_ops(4): The parameter SHOULD NOT be specified. If specified, it MUST include "derive key"(7) and/or "derive bits"(8).
• etc.

Generic Key Type for HPKE KEM A generic key type for the HPKE KEM keys including a post-quantum KEM defined in the future is defined. Even KEM keys that can be represented by existing key types can use the generic key type defined here.

Key Type for JWK A new generic key type (kty) value "HPKE-KEM" is defined to represent the private and public key used for the HPKE KEM. A key with this kty has the following parameters:

• The parameter "kty" MUST be "HPKE-KEM".
• The parameter "hkc" MUST be present and contains the HPKE Key Configuration defined in Section 3.1.1.
• The parameter "pub" MUST be present and contains the public key encoded using the base64url [RFC4648] encoding.
• The parameter "priv" MUST be present if the key is private key and contains the private key encoded using the base64url [RFC4648] encoding.

Key Type for COSE_Key A new generic kty(1) value HPKE-KEM(T.B.D.) is defined to represent the private and public key used for the HPKE KEM. A key with this kty has the following parameters:

• The parameter kty(1) MUST be HPKE-KEM(T.B.D).
• The parameter hkc(T.B.D.) MUST be present and contains the HPKE Key Configuration defined in Section 3.2.1.
• The parameter pub(-1) MUST be present and contains the public key encoded in a byte string (bstr type).
• The parameter priv(-2) MUST be present if the key is private key and contains the private key encoded in a byte string (bstr type).

Security Considerations TODO

IANA Considerations TODO

Normative References This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. 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. 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 defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). 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.

Examples

JWK for DHKEM(P-256, KDF-SHA256) Public Key with Key Type "EC"

JWK for DHKEM(X25519, KDF-SHA256) Public Key with Key Type "OKP"

JWK for DHKEM(X25519, KDF-SHA256) Private Key with Key Type "HPKE-KEM"

COSE_Key for DHKEM(P-256, KDF-SHA256) Public Key with Key Type EC2(2)

COSE_Key for DHKEM(X25519, KDF-SHA256) Public Key with Key Type OKP(1)

COSE_Key for DHKEM(X25519, KDF-SHA256) Private Key with Key Type HPKE-KEM(T.B.D)

Acknowledgments We would like to thank Ilari Liusvaara, Laurence Lundblade and Orie Steele for their review feedback.