Here is the proposal I made for adding a protected header to the json serialization.
https://github.com/OR13/draft-jose-hpke-test-vectors/pull/1/files This PR: - adds a protected header to the json serialization for HPKE JWE. - uses the protected header as aad for both seal and open HPKE operations - uses the protected header as aad for both encrypt and decrypt content encryption operations The `enc` parameter is redundant to the `alg` for HPKE suites, but I included to for aesthetic consistency with: https://datatracker.ietf.org/doc/html/rfc7516#section-3.3 Regards, OS On Tue, Jan 23, 2024 at 7:12 AM tirumal reddy <[email protected]> wrote: > Hi Illari, > > Please see inline > > On Mon, 22 Jan 2024 at 18:39, Ilari Liusvaara <[email protected]> > wrote: > >> On Mon, Jan 22, 2024 at 10:56:01AM +0530, tirumal reddy wrote: >> > Hi all, >> > >> > This revision of the draft >> > https://datatracker.ietf.org/doc/html/draft-rha-jose-hpke-encrypt >> addresses >> > comments from Illari. >> > Further comments and suggestions are welcome. >> > >> > Cheers, >> > -Tiru >> > >> > ---------- Forwarded message --------- >> > From: <[email protected]> >> > Date: Mon, 22 Jan 2024 at 10:53 >> > Subject: New Version Notification for draft-rha-jose-hpke-encrypt-02.txt >> > To: Michael B. Jones <[email protected]>, Tirumaleswar >> Reddy.K < >> > [email protected]>, Aritra Banerjee <[email protected]>, Hannes >> > Tschofenig <[email protected]>, Hannes Tschofenig < >> > [email protected]>, Orie Steele <[email protected]> >> > >> > >> > A new version of Internet-Draft draft-rha-jose-hpke-encrypt-02.txt has >> been >> > successfully submitted by Tirumaleswar Reddy and posted to the >> > IETF repository. >> > >> > Name: draft-rha-jose-hpke-encrypt >> > Revision: 02 >> > Title: Use of Hybrid Public-Key Encryption (HPKE) with Javascript >> Object >> > Signing and Encryption (JOSE) >> > Date: 2024-01-22 >> > Group: Individual Submission >> > Pages: 16 >> > URL: >> https://www.ietf.org/archive/id/draft-rha-jose-hpke-encrypt-02.txt >> > Status: https://datatracker.ietf.org/doc/draft-rha-jose-hpke-encrypt/ >> > HTML: >> > https://www.ietf.org/archive/id/draft-rha-jose-hpke-encrypt-02.html >> > HTMLized: >> https://datatracker.ietf.org/doc/html/draft-rha-jose-hpke-encrypt >> > Diff: >> > >> https://author-tools.ietf.org/iddiff?url2=draft-rha-jose-hpke-encrypt-02 >> >> Reading the updated draft, I thought, okay, how badly did I screw it up? >> >> >> 1) The draft in multiple places refers to "Direct Key Agreement". What >> it does is not DKA, but completely new kind of mode for JWE that >> directly encrypts the message with HPKE. Obviously JWE does not have >> existing term for that kind of mode! >> >> The use of this mode is specific to compact serialization, so references >> to "Direct Key Agreement" should be replaced with "compact >> serialization". >> > > It is a variation of Direct Key Agreement mode that not only generates the > CEK but also encrypts the payload. > I will update the draft to make it clear. > > >> >> >> 2) Similarly, multiple places refer to "Key Agreement with Key >> Wrapping". The mode looks more what JWE calls "Key Encryption". >> > > It is similar to ECDH+AESKW, which also defines it as a Key Agreement with > Key Wrapping mode for wrapping or encrypting the CEK (see > https://datatracker.ietf.org/doc/html/rfc7518#section-4.6). > . > > >> >> The use of this mode is specific to JSON serialization, so references to >> "Key Agreement with Key Wrapping" should be replaced with "JSON >> serialization". >> > > CEK wrapping is also possible with compact JSON serialization. > > >> >> >> 3) It is not possible to use "encapsulated_key" (which could be >> shortened to "ek") in compact serialization. >> > > Replaced "ek" with "encapsulated_key". > > >> >> This is because of cyclic dependency: To call HPKE SealBase(), you >> need the HPKE enc, but to get the HPKE enc, you need to call HPKE >> SealBase(). Deadlock. >> > > I don't get the deadlock, SealBase is invoked by using the recipient's > public key (pkR). > > >> >> For compact serialization, my proposal was to put HPKE enc (raw, as >> JWE implicitly does base64url on it) into "JWE encrypted key". >> > > Yes, it is already discussed in > https://datatracker.ietf.org/doc/html/draft-rha-jose-hpke-encrypt-02#section-6.1 > . > > >> >> >> 4) The "zip" only has special effect in compact serialization, in >> JSON serialization it does normal JWE thing. >> > > My understanding is the "zip" parameter is not specific to JSON compact > serialization; it can be used in both compact and JSON serialization. > > >> >> And the decryption section could add parenthetical that the message is >> possibly compressed. >> > > Yes, added following text: > If a "zip" parameter is included, the recipient will uncompress the > decrypted plaintext using the specified compression algorithm. > > >> >> >> 5) The aad construction should refer to step 14 of S5.1 of JWE, >> instead of whole S5.1 of JWE. >> > > Fixed. > > >> >> >> 6) Using strcture from S4.6.2. of JWA for info is nonsensical. >> >> That strcture is of completely wrong type: It is KDF input, not KDF >> context. HPKE has its own internal KDF. >> >> And that is not the only problem: >> - HPKE uses multiple key data lengths for even one ciphersuite, making >> key data length ill-defined. E.g., AES-128-GCM uses both 128 and 96. >> > > I don't see multiple key data lengths specified in Section 7.3 of > https://datatracker.ietf.org/doc/rfc9180/ for AES-128-GCM. > > >> - HPKE KDF already includes ciphersuite, making AlgorithmID unnecessary. > > > Please point me to the relevant section in 9180 about KDF including > ciphersuite. > > >> - PartyUInfo uses insecure copy, making it a footgun. >> > > Are you referring to any specific JOSE implementation which uses insecure > copy ? > > >> - HPKE lacks sender/receiver symmetry, so PartyUInfo/PartyVInfo are >> unnecessary. >> > > I don't get it, please elaborate. > > >> >> Furthermore, using info input causes problems with some HPKE >> implementations: >> >> - Some implementations do not allow specifying aad and info >> simultaneously. >> - Some implementations have 64 byte limit for info. >> > > I don't see any such restrictions imposed in the specification of OHAI > which uses "info". > > >> >> >> 7) There is no need to discuss what SealBase() and OpenBase() do >> internally. >> > > Yes, it can be removed. > > Cheers, > -Tiru > > >> >> >> Reiterating my earlier proposal as mapping between HPKE inputs/outputs >> and JWE constructs (with fixes to aad construction): >> >> a) Compact serialization: >> >> HPKE public key <---> Converted public key. >> HPKE private key <---> Converted private key. >> HPKE plaintext <---> (possibly compressed) message. >> HPKE enc <---> JWE encrypted key. >> HPKE ciphertext <---> JWE ciphertext. >> HPKE aad <---> As specified by step 14 of S5.1 of JWE. >> HPKE info <---> (empty) >> (empty) <---> JWE Initialization Vector. >> (empty) <---> JWE Authentication Tag. >> >> b) JSON serialization: >> >> HPKE public key <---> Converted public key. >> HPKE private key <---> Converted private key. >> HPKE plaintext <---> CEK. >> BASE64URL(HPKE enc) <---> Unprotected recipient encapsulated_key. >> HPKE ciphertext <---> receipient JWE Encrypted Key. >> HPKE aad <---> (empty) >> HPKE info <---> (empty) >> >> >> The slight misalignment between the two seems unavoidable. >> >> >> >> >> -Ilari >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >> > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
