COSE Key and JSON Web Key Representation for Key Encapsulation Mechanism (KEM) of Hybrid Public Key Encryption (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 1 August 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

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

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

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

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

5. Security Considerations

TODO¶

6. IANA Considerations

TODO¶

Appendix A. Examples

{
    "kty": "OKP",
    "kid": "01",
    "crv": "X25519",
    "alg": "HPKE-v1-Base",
    "hkc": {
        "kem": 0x020,
        "kdfs": [0x001, 0x002, 0x003],
        "kems": [0x001, 0x002]
    },
    "x": "y3wJq3uXPHeoCO4FubvTc7VcBuqpvUrSvU6ZMbHDTCI"
}

{
    "kty": "HPKE-KEM",
    "kid": "01",
    "alg": "HPKE-v1-Base",
    "hkc": {
        "kem": 0x021,
        "kdfs": [0x001, 0x002, 0x003],
        "kems": [0x001, 0x002]
    },
    "pub": "IkLmc0klvEMXYneHMKAB6ePohryAwAPVe2pRSffIDY6NrjeYNWVX5J-fG4NV2OoU77C88A0mvxI",
    "priv": "rJJRG3nshyCtd9CgXld8aNaB9YXKR0UOi7zj7hApg9YH4XdBO0G8NcAFNz_uPH2GnCZVcSDgV5c"
}

  {
    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'
  }

  {
    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)
        0x0021,                    // 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