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). -Tiru > >>> >>> >>> >>> -Ilari >>> >>> _______________________________________________ >>> jose mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> >> *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] >> > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
