Thank you for these comments!
Would you mind filling in the HPKE Operations for this part of your
proposal:
HPKE ciphertext = Seal(key, nonce, aad, pt)
HPKE plaintext = Open(key, nonce, aad, ct)
But using the variables you defined below:
*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 <---> recipient JWE Encrypted Key.HPKE aad
<---> (empty)HPKE info <---> (empty)*
And then finally structuring an example for each serialization with the
variables in places of values in the correct places?
It's not obvious to me how to map the right hand side to the exact
serializations that are needed (especially for JSON).
For example:
{ protected: <<what goes here>>, unprotected: <<what goes here>>, iv:
undefined, ciphertext: base64url(*recipient JWE Encrypted Key ?*) }
In the JWE Compact Serialization, a JWE is represented as the
concatenation:
BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' ||
BASE64URL(JWE Initialization Vector) || '.' ||
BASE64URL(JWE Ciphertext) || '.' ||
BASE64URL(JWE Authentication Tag)
I can probably implement the result and generate some test vectors for
other implementations to confirm.
The primary challenge here is giving a precise description of how protected
headers are related to AAD.
OS
On Mon, Jan 22, 2024 at 7:09 AM 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".
>
>
> 2) Similarly, multiple places refer to "Key Agreement with Key
> Wrapping". The mode looks more what JWE calls "Key Encryption".
>
> The use of this mode is specific to JSON serialization, so references to
> "Key Agreement with Key Wrapping" should be replaced with "JSON
> serialization".
>
>
> 3) It is not possible to use "encapsulated_key" (which could be
> shortened to "ek") in compact serialization.
>
> 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.
>
> For compact serialization, my proposal was to put HPKE enc (raw, as
> JWE implicitly does base64url on it) into "JWE encrypted key".
>
>
> 4) The "zip" only has special effect in compact serialization, in
> JSON serialization it does normal JWE thing.
>
> And the decryption section could add parenthetical that the message is
> possibly compressed.
>
>
> 5) The aad construction should refer to step 14 of S5.1 of JWE,
> instead of whole S5.1 of JWE.
>
>
> 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.
> - HPKE KDF already includes ciphersuite, making AlgorithmID unnecessary.
> - PartyUInfo uses insecure copy, making it a footgun.
> - HPKE lacks sender/receiver symmetry, so PartyUInfo/PartyVInfo are
> unnecessary.
>
> 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.
>
>
> 7) There is no need to discuss what SealBase() and OpenBase() do
> internally.
>
>
>
> 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
>
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
