]> 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 configuration of 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 Standardized by the Internet Research Task Force (IRTF), Hybrid Public Key Encryption (HPKE) 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. This document defines how to represent the HPKE KEM key configuration information in COSE_Key and JWK. Specifically, this document defines (1) a common key parameter for defining the HPKE KEM 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 a post-quantum KEM to be specified in the future. 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. It MUST contain the object consisting of the following three attributes. A JWK used for HPKE KEM MUST have this parameter.

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

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 one of the following values if specified. If omitted, it MUST be treated as "HPKE-v1-Base".
  • "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:

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 one of the following values if specified. If omitted, it MUST be treated as HPKE-v1-Base(T.B.D.).
  • 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 X.X.
• 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 X.X.
• The parameter pub(-1) MUST be present and contains the public key encoded using the base64url [RFC4648] encoding.
• The parameter priv(-2) MUST be present if the key is private key and contains the private key encoded using the base64url [RFC4648] encoding.

Security Considerations TODO

IANA Considerations TODO

Normative References 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(X25519, KDF-SHA-256) Public Key with Key Type "OKP"

JWK for DHKEM(X448, KDF-SHA-512) Private Key with Key Type "HPKE-KEM"

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

COSE_Key for DHKEM(X448, KDF-SHA-512) Private Key with Key Type HPKE-KEM(T.B.D)

Acknowledgments TODO acknowledge.