On Fri, Jun 14, 2024 at 01:22:32PM +0530, tirumal reddy wrote: > On Thu, 13 Jun 2024 at 21:02, Ilari Liusvaara <[email protected]> > wrote: > > > > c) Direct HPKE: Two options under discussion a) place encapsulated key in > > > "ek" b) place encapsulated key in "JWE Encrypted Key". > > > > It turns out to depend on how "enc:dir" is defined which of these is > > possible. > > > > It can be defined as follows: > Direct use of a fully specified encryption suite in the alg parameter that > specifies the KEM for key agreement, the KDF for generating the final > shared secret, and the AEAD for encrypting the payload.
I mean specifying how encryption and decryption is done in that mode, similar to JWE sections 5.1 and 5.2. > > The definition of "enc:dir" has to be significantly more complex to make > > it even possible to use headers in compact serialization. > > > Can you elaborate why it would have to be much more complex to use new > headers in compact serialization ? The "enc:dir" would have to be defined to invoke two different new algorithm operations, the first to set up the headers and the second to perform actual encryption. As opposed to invoking just one new algorithm operation that does the whole algorithm-specific part of encryption. > > > > Note that type of KEM is not listed. Because it is internal detail > > > > that is not important to anything but implementation of the KEM itself. > > > > > > Yes, it is an internal detail but the JWE Encrypted Key definition would > > > have to be updated. > > > > "enc:dir" has to redefine JWE Encrypted key anyway. Because there is no > > "Content Encryption Key" (which has very specific meaning in JOSE). > > > > Dealing with JWE Encrypted Key in "enc:dir" is simple, dealing with > > headers in "enc:dir" is not. > > > > If the encapsulated key is conveyed in "ek", JWE Encrypted key will be an > empty octect sequence and no need to redefine it. All JWE modes explicitly define what goes into JWE Encrypted Key. > > HPKE does not bind encapsulation key to shared secret. > > > > No, the encapsulated key is passed as KEM context in ExtractAndExpand > function to derive the final shared secret (see Encap function in RFC9180). Any KEM that is not DHKem redefines that function. And it can do it in a way that does not bind encapsulated key to shared secret (modulo what IND-CCA requires). -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
