CBOR Object Signing and Encryption D. Ajitomi Internet-Draft Independent Intended status: Standards Track 23 January 2023 Expires: 27 July 2023 COSE Key and JSON Web Key Representation for Key Encapsulation Mechanism (KEM) of Hybrid Public Key Encryption (HPKE) draft-ajitomi-cose-key-jwk-hpke-latest Abstract 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 This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://dajiaji.github.io/i-d-cose-key-jwk-hpke/draft-ajitomi-cose- key-jwk-hpke.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ajitomi-cose-key-jwk-hpke/. Discussion of this document takes place on the CBOR Object Signing and Encryption Working Group mailing list (mailto:cose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/cose/. Source for this draft and an issue tracker can be found at https://github.com/dajiaji/i-d-cose-key-jwk-hpke. 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 27 July 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Conventions and Definitions 3. Common Key Parameter for HPKE KEM 3.1. JWK Parameter 3.2. COSE Key Common Parameter 4. Generic Key Type for HPKE KEM 4.1. Key Type "HPKE-KEM" for JWK 4.2. Key Type HPKE-KEM for COSE_Key 5. Security Considerations 6. IANA Considerations 7. Normative References Appendix A. Examples A.1. JWK for DHKEM(X25519, KDF-SHA-256) Public Key with Key Type "OKP" A.2. JWK for DHKEM(X448, KDF-SHA-512) Private Key with Key Type "HPKE-KEM" A.3. COSE_Key for DHKEM(X25519, KDF-SHA-256) Public Key with Key Type OKP(1) A.4. COSE_Key for DHKEM(X448, KDF-SHA-512) Private Key with Key Type HPKE-KEM(T.B.D) Acknowledgments Author's Address 1. Introduction Standardized by the Internet Research Task Force (IRTF), HPKE has already been adopted in several communication protocol specifications such as Encrypted Client Hello (ECH), Oblivious DNS over HTTP (ODoH) and Oblivious HTTP (OHTTP). The 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 sending a ciphertext needs to know in advance the KEM supported by the recipient and its public key, as well as the HPKE mode, the set of supported KDF and AEAD algorithms. For example, ECH defines this information as a structure called HpkeKeyConfig. The way in which this information is exchanged is out-of-scope of the specification, but it is assumed that it is obtained in advance by the sender, for example via DNS HTTPS RRs. This document defines how to represent the HPKE KEM key configuration information corresponding to the ECH HpkeKeyConfig in COSE_Key and JWK. Specifically, this document defines (1) a 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 JWKs, which are widely used as public key representations at the application layer, and their binary representation, COSE_Key, will facilitate the use of HPKE in a wide variety of web applications and communication systems for constrained devices. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Common Key Parameter for HPKE KEM The KEM 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 common key parameters is also defined. 3.1. JWK Parameter The KEM key configuration parameter for JWK is defined as follows: * "hkc" (HPKE Key Configuration): The parameter 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. The restrictions on the use of existing common key parameters in a JWK for the 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. 3.2. COSE Key Common Parameter The KEM 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 = [ kem: uint, ; KEM identifier kdfs: uint / [+uint], ; KDF identifiers aeads: uint / [+uint], ; AEAD identifiers ] +---------+----------------+-------------+----------------------+ | Name | CBOR Type | Value | Description | | | | Registry | | +---------+----------------+-------------+----------------------+ | kem | uint | HPKE KEM | The KEM identifier | | | | Identifiers | bound to the key | | | | | | | kdfs | uint / [+uint] | HPKE KDF | The KDF identifiers | | | | Identifiers | supported by the | | | | | recipient | | | | | | | aeads | uint / [+uint] | HPKE AEAD | The AEAD identifiers | | | | Identifiers | supported by the | | | | | recipient | | | | | | +---------+----------------+-------------+----------------------+ 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. 4. 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. 4.1. Key Type "HPKE-KEM" 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. 4.2. Key Type HPKE-KEM 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. 5. Security Considerations TODO 6. IANA Considerations TODO 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Appendix A. Examples A.1. JWK for DHKEM(X25519, KDF-SHA-256) Public Key with Key Type "OKP" { "kty": "OKP", "kid": "01", "crv": "X25519", "alg": "HPKE-v1-Base", "hkc": { "kem": 0x020, "kdfs": [0x001, 0x002, 0x003], "kems": [0x001, 0x002], }, "x": "y3wJq3uXPHeoCO4FubvTc7VcBuqpvUrSvU6ZMbHDTCI" } A.2. JWK for DHKEM(X448, KDF-SHA-512) Private Key with Key Type "HPKE- KEM" { "kty": "HPKE-KEM", "kid": "01", "alg": "HPKE-v1-Base", "hkc": { "kem": 0x020, "kdfs": [0x001, 0x002, 0x003], "kems": [0x001, 0x002], }, "pub": "IkLmc0klvEMXYneHMKAB6ePohryAwAPVe2pRSffIDY6NrjeYNWVX5J-fG4NV2OoU77C88A0mvxI", "priv": "rJJRG3nshyCtd9CgXld8aNaB9YXKR0UOi7zj7hApg9YH4XdBO0G8NcAFNz_uPH2GnCZVcSDgV5c" } A.3. COSE_Key for DHKEM(X25519, KDF-SHA-256) Public Key with Key Type OKP(1) { 1:1, // OKP 2:'01', 3:-1(T.B.D), // HPKE-v1-Base -1:4, // X25519 6(T.B.D): [ // hkc (HPKE Key Configuration) 0x0020, [0x0001, 0x0002, 0x0003], [0x0001, 0x0002] ], -2:h'd75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a' } A.4. COSE_Key for DHKEM(X448, KDF-SHA-512) Private Key with Key Type HPKE-KEM(T.B.D) { 1:-1(T.B.D.), // HPKE-KEM 2:'01', 3:-1(T.B.D), // HPKE-v1-Base 6(T.B.D): [ // hkc (HPKE Key Configuration) 0x0020, // KEM id [0x0001, 0x0002, 0x0003], // supported KDF ids [0x0001, 0x0002] // supported AEAD ids ], -1:h'5fd7449b59b461fd2ce787ec616ad46a1da1342485a70e1f8a0ea75d80e96778edf124769b46c7061bd6783df1e50f6cd1fa1abeafe8256180', -2:h'6c82a562cb808d10d632be89c8513ebf6c929f34ddfa8c9f63c9960ef6e348a3528c8a3fcc2f044e39a3fc5b94492f8f032e7549a20098f95b' } Acknowledgments TODO acknowledge. Author's Address Daisuke Ajitomi Independent Email: ajitomi@gmail.com