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

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

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¶

Acknowledgments

TODO acknowledge.¶

Author's Address