Internet-Draft | JOSE-COSE HPKE Cookbook | March 2024 |
Steele | Expires 3 September 2024 | [Page] |
This document contains a set of examples using JSON Object Signing and Encryption (JOSE), CBOR Object Signing and Encryption (COSE) and Hybrid Public Key Encryption (HPKE) to protect data. These examples are meant to coverage the edge cases of both JOSE and COSE, including different structures for single and multiple recipients, external additional authenticated data, and key derivation function (KDF) context binding.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://OR13.github.io/draft-steele-jose-cose-hpke-cookbook/draft-steele-jose-cose-hpke-cookbook.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-steele-jose-cose-hpke-cookbook/.¶
Discussion of this document takes place on the Javascript Object Signing and Encryption Working Group mailing list (mailto:jose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/jose/. Subscribe at https://www.ietf.org/mailman/listinfo/jose/.¶
Source for this draft and an issue tracker can be found at https://github.com/OR13/draft-steele-jose-cose-hpke-cookbook.¶
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 3 September 2024.¶
Copyright (c) 2024 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 is inspired by Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) [RFC7520].¶
JOSE support for HPKE is described in [I-D.draft-rha-jose-hpke-encrypt].¶
COSE support for HPKE is described in [I-D.draft-ietf-cose-hpke].¶
Both drafts are still work in progress.¶
The current set of examples are incomplete.¶
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.¶
The term "JSON Web Key (JWK)" is defined in [RFC7517].¶
The term "COSE Key" is defined in [RFC9052].¶
The terms "JSON Web Encryption (JWE)", "Direct Key Agreement", "Key Agreement with Key Wrapping", "JWE Compact Serialization" and "General JWE JSON Serialization" are defined in [RFC7516].¶
The terms "Direct Encryption", and "Key Agreement with Key Wrap" are defined in [RFC9052].¶
The term "encapsulated key" is defined in [RFC9180].¶
This document does not define any new terms for JOSE or COSE.¶
Note that JSON (JavaScript Object Notation) and EDN (Extended Diagnostic Notation) may not exactly match the bytes provided for each example.¶
The hexadecimal encoded binary messages are the source of truth, the JSON and EDN examples are for readability.¶
NOTE: '' line wrapping per [RFC8792] in HTTP examples.¶
This section provides private key representations that are used throught the following sections.¶
Public key representations for these keys are left as an excercise for the reader.¶
The keys in this section are restricted to a single algorithm in both JOSE and COSE: HPKE-Base-P256-SHA256-AES128GCM
.¶
Additional algorithms and their private key representations may be provided in future versions of this draft.¶
This section provides a JSON Web Key for HPKE-Base-P256-SHA256-AES128GCM
.¶
This section provides a COSE Key for HPKE-Base-P256-SHA256-AES128GCM
.¶
JOSE and COSE HPKE both support a "Direct Encryption Mode", where HPKE encrypt a plaintext message and optional additional authenticated data directly to a recipient public key.¶
Note that HPKE Direct Encryption is not exactly the same as "Direct Encryption" as described in [RFC7516] and [RFC9052].¶
In this section we provide direct encryption examples to the private keys in the previous section.¶
Note that JOSE and COSE transport the encapsulated key "ek" differently.¶
JOSE and COSE HPKE both support a "Key Encryption Mode", where HPKE encrypt a content encryption key to a recipient public key, and a plaintext message and optional additional authenticated with the content encryption key.¶
Note that HPKE Key Encryption Mode is not exactly the same as "Key Agreement with Key Wrap" as described in [RFC7516] and [RFC9052].¶
In this section we provide direct encryption examples to the private keys in the previous section.¶
Note that the ephemeral public key (epk) is present in the protected header due to there only being a single recipient for this message.¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶