On Sun, Jun 9, 2024 at 11:06 PM tirumal reddy <[email protected]> wrote:
> On Sat, 8 Jun 2024 at 02:39, Orie Steele <[email protected]> > wrote: > >> >> >> On Fri, Jun 7, 2024, 3:09 PM Brian Campbell <bcampbell= >> [email protected]> wrote: >> >>> Couching my comments inline below with my own experience or lack >>> thereof: I've got a 10+ year old JOSE/JWT implementation that supports JWE >>> compact serialization and is still in (relatively) widespread use, so I >>> have some knowledge in that area. However, I'm only a casual observer of >>> HPKE and the efforts to bring its wisdom down from the mountain to JOSE. >>> >>> >>> On Tue, Jun 4, 2024 at 4:44 AM Ilari Liusvaara <[email protected]> >>> wrote: >>> >>>> On Sun, Jun 02, 2024 at 10:56:35AM -0500, Orie Steele wrote: >>>> > I've suggested a change to JOSE HPKE to align it with COSE HPKE: >>>> > >>>> > https://github.com/tireddy2/JOSE_HPKE/pull/26 >>>> > <https://github.com/tireddy2/JOSE_HPKE/pull/26/files> >>>> > >>>> > If there is consensus to make this change, I can update my prototype >>>> and >>>> > regenerate examples for the draft, and the cookbook: >>>> >>>> Sure, it is better. >>>> >>> >>> I agree that it's better to not use the "epk" (ephemeral public key) >>> <https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6.1.1> header >>> for something that sure doesn't seem like a public key (ephemeral or >>> otherwise). Also noting that "epk" was specified in the context of JWE's >>> ECDH >>> Key Agreement <https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6>. >>> >> >> enc or encapsulated key is an ephemeral public key for DHKems, but for PQ >> KEMs like ML-KEM, it is KEM ciphertext. >> >> I suggest reading RFC9180 (from memory this is the HPKE RFC, possible my >> memory is wrong) to get a feel for the HPKE Kem interface. >> >> >>> >>> >>> >>>> However, there is this text in RFC 7516, section 5.1.: >>>> >>>> 4. When Key Wrapping, Key Encryption, or Key Agreement with Key >>>> Wrapping are employed, encrypt the CEK to the recipient and let >>>> the result be the JWE Encrypted Key. >>>> >>>> Which seems to say that the whole output should go into JWE Encrypted >>>> Key. >>> >>> >>> As the aforestated casual observer, I have not understood why the JWE >>> Encrypted Key isn't a good place to put the encapsulated key. >>> >> >> In the case of multiple recipient hpke, you have a kem ciphertext and an >> encrypted content encryption key per recipient, similar to what you see in >> a message encrypted with both ECDH-ES+A128KW, and ECDH-ES+A256KW. >> >> In the case of direct HPKE encryption, you have a single recipient, and >> HPKE encrypts the plaintext directly without an intermediate content >> encryption key being externalized. >> >> Most of the discussion we've had so far has been about if it's easier to >> reuse an existing parameter for HPKE or if we should create new parameters >> that are specific to HPKE. >> >> If I understand Ilari's comment, he suggests that when HPKE is used to >> encrypt a cek, the JWE Encrypted Key is the concatenation of the kem >> ciphertext and the aead ciphertext. >> >> This would require implementations to split this base64url encoded >> concatenated string for each HPKE kem, in order to decrypt the content >> encryption key. >> >> I tend to prefer using JSON, or CBOR to handle distinct parameters, >> instead of splitting binary or text encoded binary in a single envelope >> parameter. >> > > Yes, I don't see a need to overload the JWE Encrypted Key to carry the > encrypted CEK and KEM ciphertext. Introducing a new parameter to carry the > KEM ciphertext does not break the procedure in steps 3 and 4 of Section 5.1 > of RFC7516. > > >> >>> >>> >>> >>>> The algorithm can not be Key Agreement with Key Wrapping, because >>>> then step 3 would come to play, and it wants "the key agreement >>>> algorithm to compute the value of the agreed upon key" (something that >>>> requires exporters in HPKE). >>>> >>>> There is of course two outputs. Naive concatenation would work, because >>>> length of enc is determined by KEM (it is even listed in IANA registry), >>>> which is determined by alg. >>>> >>>> >>>> As for the other mode, JWE as of currently defined does not allow it. >>>> What the draft currently does with it is flat out Undefined Behavior. >>> >>> > If you are referring to HPKE Direct Encryption mode, it is a new mode > (similar to one defined in COSE HPKE spec). > I'm not sure but maybe he's referring to how that 4.4.1. HPKE Direct Encryption <https://www.ietf.org/archive/id/draft-rha-jose-hpke-encrypt-07.html#name-hpke-direct-encryption> uses the JWE "dir" alg in an inappropriate and non-compliant way? The 'dir" Key Management algorithm for JWE is defined in JWA as Direct Encryption with a Shared Symmetric Key <https://www.rfc-editor.org/rfc/rfc7518.html#section-4.5>, which is not what's happening with that HPKE Direct Encryption mode. That's something that probably needs to be addressed regardless of what Ilari was actually referring to here. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
