Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)

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 22 July 2025.¶

Copyright Notice

Copyright (c) 2025 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.¶

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.¶

Table of Contents

1. Introduction

Hybrid public-key encryption (HPKE) [RFC9180] is a scheme that provides public key encryption of arbitrary-sized plaintexts given a recipient's public key.¶

This document defines the use of the HPKE with COSE ([RFC9052], [RFC9053]).¶

2. Conventions and Terminology

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

This specification uses the following abbreviations and terms:¶

• Content-encryption key (CEK), a term defined in CMS [RFC2630].¶

• Hybrid Public Key Encryption (HPKE) is defined in [RFC9180].¶

• pkR is the public key of the recipient, as defined in [RFC9180].¶

• skR is the private key of the recipient, as defined in [RFC9180].¶

• Key Encapsulation Mechanism (KEM), see [RFC9180].¶

• Key Derivation Function (KDF), see [RFC9180].¶

• Authenticated Encryption with Associated Data (AEAD), see [RFC9180].¶

• Additional Authenticated Data (AAD), see [RFC9180].¶

3. HPKE for COSE

Recipient_structure = [
    context: "Recipient",
    next_layer_alg: int/tstr,
    recipient_protected_header: empty_or_serialize_map,
    recipient_aad: bstr
]

4. Ciphersuite Registration

A ciphersuite is a group of algorithms, often sharing component algorithms such as hash functions, targeting a security level. A COSE-HPKE algorithm is composed of the following choices:¶

• HPKE Mode¶

• KEM Algorithm¶

• KDF Algorithm¶

• AEAD Algorithm¶

The "KEM", "KDF", and "AEAD" values are chosen from the HPKE IANA registry [HPKE-IANA].¶

For readability the algorithm ciphersuites labels are built according to the following scheme:¶

HPKE-<Version>-<Mode>-<KEM>-<KDF>-<AEAD>

The "Mode" indicator may be populated with the following values from Table 1 of [RFC9180]:¶

• "Base" refers to "mode_base" described in Section 5.1.1 of [RFC9180], which only enables encryption to the holder of a given KEM private key.¶

• "PSK" refers to "mode_psk", described in Section 5.1.2 of [RFC9180], which authenticates using a pre-shared key.¶

• "Auth" refers to "mode_auth", described in Section 5.1.3 of [RFC9180], which authenticates using an asymmetric key.¶

• "Auth_Psk" refers to "mode_auth_psk", described in Section 5.1.4 of [RFC9180], which authenticates using both a PSK and an asymmetric key.¶

For a list of ciphersuite registrations, please see Section 7. The following table summarizes the relationship between the ciphersuites registered in this document, which all use the "Base" mode and the values registered in the HPKE IANA registry [HPKE-IANA].¶

+--------------------------------------------------+------------------+
| COSE-HPKE                                        |      HPKE        |
| Cipher Suite Label                               | KEM | KDF | AEAD |
+--------------------------------------------------+-----+-----+------+
| HPKE-0                                           |0x10 | 0x1 | 0x1  |
| HPKE-1                                           |0x11 | 0x2 | 0x2  |
| HPKE-2                                           |0x12 | 0x3 | 0x2  |
| HPKE-3                                           |0x20 | 0x1 | 0x1  |
| HPKE-4                                           |0x20 | 0x1 | 0x3  |
| HPKE-5                                           |0x21 | 0x3 | 0x2  |
| HPKE-6                                           |0x21 | 0x3 | 0x3  |
+--------------------------------------------------+-----+-----+------+

As the list indicates, the ciphersuite labels have been abbreviated at least to some extend to maintain the tradeoff between readability and length.¶

The ciphersuite list above is a minimal starting point. Additional ciphersuites can be registered into the already existing registry. For example, once post-quantum cryptographic algorithms have been standardized it might be beneficial to register ciphersuites for use with COSE-HPKE. Additionally, ciphersuites utilizing the compact encoding of the public keys, as defined in [I-D.irtf-cfrg-dnhpke], may be standardized for use in constrained environments.¶

As a guideline for ciphersuite submissions to the IANA CoSE algorithm registry, the designated experts must only register combinations of (KEM, KDF, AEAD) triple that consitute valid combinations for use with HPKE, the KDF used should (if possible) match one internally used by the KEM, and components should not be mixed between global and national standards.¶

+---------------------+--------------+
| HPKE KEM id         | COSE_Key     |
|                     | kty | crv    |
+---------------------+-----+--------+
| 0x0010, 0x0013      | EC2 | P-256  |
| 0x0011, 0x0014      | EC2 | P-384  |
| 0x0012, 0x0015      | EC2 | P-521  |
| 0x0020              | OKP | X25519 |
| 0x0021              | OKP | X448   |
+---------------------+-----+--------+

5. Examples

This section provides a set of examples that shows all COSE message types (COSE_Encrypt0, COSE_Encrypt and COSE_MAC) to which the COSE-HPKE can be applied, and also provides some examples of key representation for HPKE KEM.¶

Each example of the COSE message includes the following information that can be used to check the interoperability of COSE-HPKE implementations:¶

• plaintext: Original data of the encrypted payload.¶

• external_aad: Externally supplied AAD.¶

• skR: A recipient private key.¶

• skE: An ephemeral sender private key paired with the encapsulated key.¶

16([
    / alg = HPKE-0 (Assumed: 35) /
    h'a1011823',
    {
        / kid /
        4: h'3031',
        / ek /
        -4: h'045df24272faf43849530db6be01f42708b3c3a9
              df8e268513f0a996ed09ba7840894a3fb946cb28
              23f609c59463093d8815a7400233b75ca8ecb177
              54d241973e',
    },
    / encrypted plaintext /
    h'35aa3d98739289b83751125abe44e3b977e4b9abbf2c8cfaade
      b15f7681eef76df88f096',
])

96_0([
    / alg = AES-128-GCM (1) /
    h'a10101',
    {
        / iv /
        5: h'b3fb95dde18c6f90a9f0ae55',
    },
    / detached ciphertext /
    null,
    [
        [
            / alg = HPKE-0 (Assumed: 35) /
            h'a1011823',
            {
                / kid /
                4: h'3031',
                / ek /
                -4: h'04d97b79486fe2e7b98fb1bd43
                      c4faee316ff38d28609a1cf568
                      40a809298a91e601f1cc0c2ba4
                      6cb67b41f4651b769cafd9df78
                      e58aa7f5771291bd4f0f420ba6',
            },
            / ciphertext containing encrypted CEK /
            h'24450f54ae93375351467d17aa7a795cfede2
              c03eced1ad21fcb7e7c2fe64397',
        ],
        [
            / alg = HPKE-4 (Assumed: 42) /
            h'a101182a',
            {
                / kid /
                4: h'3032',
                / ek /
                -4: h'd1afbdc95b0e735676f6bca34f
                      be50f2822259ac09bfc3c500f1
                      4a05de9b2833',
            },
            / ciphertext containing encrypted CEK /
            h'079b443ec6dfcda6a5f8748aff3875146a8ed
              40359e1279b545166385d8d9b59',
        ],
    ],
])

18(
  [
    / protected / h'a10126' / {
            \ alg \ 1:-7 \ ECDSA 256 \
          } / ,
    / unprotected / {
          / kid / 4:'sender@example.com'
        },
    / payload /     h'AA19...B80C',
    / signature /   h'E3B8...25B8'
  ]
)

97_0([
    / alg = HMAC 256/256 (5) /
    h'a10105',
    {},
    / payload = 'This is the content.' /
    h'546869732069732074686520636f6e74656e742e',
    / tag /
    h'5cdcf6055fcbdb53b4001d8fb88b2a46b200ed28e1e
          d77e16ddf43fb3cac3a98',
    [
        [
            / alg = HPKE-0 (Assumed: 35) /
            h'a1011823',
            {
                / kid = '01' /
                4: h'3031',
                / ek /
                -4: h'043ac21632e45e1fbd733f002a
                      621aa4f3d94737adc395d5a7cb
                      6e9554bd1ad273aec991493786
                      d72616d9759bf8526e6e20c1ed
                      c41ba5739f2b2e441781aa0eb4',
            },
            / ciphertext containing encrypted MAC key /
            h'5cee2b4235a7ff695164f7a8d1e79ccf3ca3d
              e8b22f3592626020a95b2a8d3fb4d7aa7fe37
              432426ee70073a368f29d1',
        ],
        [
            / alg = HPKE-4 (Assumed: 42) /
            h'a101182a',
            {
                / kid = '02' /
                4: h'3032',
                / ek /
                -4: h'02cffacc60def3bb3d0a1c3661
                      227c9de8dc2b1d3939dd2c07d4
                      49ebb0bba324',
            },
            / ciphertext containing encrypted MAC key /
            h'3f5b8b60271d5234dbea554dc1461d0239e9f
              4589f6415e8563b061dbcb37795a616111b78
              2b4c589b534309327ffadc',
        ],
    ],
])

{
    / kty = 'EC2' /
    1: 2,
    / kid = '01' /
    2: h'3031',
    / alg = HPKE-0 (Assumed: 35) /
    3: 35,
    / crv = 'P-256' /
    -1: 1,
    / x /
    -2: h'65eda5a12577c2bae829437fe338701a10aaa375
              e1bb5b5de108de439c08551d',
    / y /
    -3: h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af
              7e0ca7ca7e9eecd0084d19c'
}

{
    / kty = 'EC2' /
    1: 2,
    / kid = '01' /
    2: h'3031',
    / alg = HPKE-0 (Assumed: 35) /
    3: 35,
    / key_ops = ['derive_bits'] /
    4: [8],
    / crv = 'P-256' /
    -1: 1,
    / x /
    -2: h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f7
              45228255a219a86d6a09eff',
    / y /
    -3: h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72
              ccfed6b6fb6ed28bbfc117e',
    / d /
    -4: h'57c92077664146e876760c9520d054aa93c3afb04
              e306705db6090308507b4d3',
}

{
    / kty = 'OKP' /
    1: 1,
    / kid = '11' /
    2: h'3131',
    / alg = HPKE-4 (Assumed: 42) /
    3: 42,
    / crv = 'X25519' /
    -1: 4,
    / x /
    -2: h'cb7c09ab7b973c77a808ee05b9bbd373b55c06eaa
              9bd4ad2bd4e9931b1c34c22',
}

6. Security Considerations

This specification is based on HPKE and the security considerations of [RFC9180] are therefore applicable also to this specification.¶

HPKE assumes the sender is in possession of the public key of the recipient and HPKE COSE makes the same assumptions. Hence, some form of public key distribution mechanism is assumed to exist but outside the scope of this document.¶

HPKE relies on a source of randomness to be available on the device. Additionally, with the two layer structure the CEK is randomly generated and it MUST be ensured that the guidelines in [RFC8937] for random number generations are followed.¶

HPKE in Base mode does not offer authentication as part of the HPKE KEM. In this case COSE constructs like COSE_Sign, COSE_Sign1, COSE_MAC, or COSE_MAC0 can be used to add authentication. HPKE also offers modes that offer authentication.¶

If COSE_Encrypt or COSE_Encrypt0 is used with a detached ciphertext then the subsequently applied integrity protection via COSE_Sign, COSE_Sign1, COSE_MAC, or COSE_MAC0 does not cover this detached ciphertext. Implementers MUST ensure that the detached ciphertext also experiences integrity protection. This is, for example, the case when an AEAD cipher is used to produce the detached ciphertext but may not be guaranteed by non-AEAD ciphers.¶

7. IANA Considerations

This document requests IANA to add new values to the 'COSE Algorithms' and to the 'COSE Header Parameters' registries.¶

8. References

Appendix A. Contributors

We would like thank the following individuals for their contributions to the design of embedding the HPKE output into the COSE structure following a long and lively mailing list discussion:¶

• Richard Barnes¶

• Ilari Liusvaara¶

Finally, we would like to thank Russ Housley and Brendan Moran for their contributions to the draft as co-authors of initial versions.¶

Appendix B. Acknowledgements

We would like to thank John Mattsson, Mike Prorock, Michael Richardson, and Goeran Selander for their review feedback.¶

Authors' Addresses