On Thu, 13 Jun 2024 at 21:02, Ilari Liusvaara <[email protected]> wrote:
> On Thu, Jun 13, 2024 at 07:10:26PM +0530, tirumal reddy wrote: > > On Thu, 13 Jun 2024 at 17:57, Ilari Liusvaara <[email protected]> > > wrote: > > > > > > Yes, I am only referring to compact serialization where there is a > problem. > > > > Summarizing the discussion so far > > a) indirect HPKE: no issue > > If one reads JWE strictly, indirect HPKE can not use headers, but I > think it is unlikely that using headers causes major problems in > practice. > > However, some versions of the draft had indirect HPKE read protected > headers, which is sure to cause major issues. > In the latest version of the draft, the CEK is encrypted using HPKE without the need to read the protected headers. > > > > b) Direct HPKE: no issue with JWE serialization but the document has to > be > > updated to use {"enc:dir", "alg: HPKE-....-A128GCM"} and the IANA > registry > > will have to be updated for "dir" that it can also be used with "Direct > use > > of a fully specified encryption suite". > > One also has to define what "enc:dir" means. > Yes. > > > > 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. > > > > > It turns out it is much easier to place it in JWE Encrypted key than > > > into headers. > > > > What is the problem if the encapsulated key is placed in another header > > which can be integrity protected ? > > 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 ? > > > > > 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. > > > > > If there was any security reason for protecting the encapsulated key, > > > then HPKE would have done that built-in. > > > > I looked into the Encap function in HPKE, which already binds the > > encapsulation key to the shared secret, so I don't see a security > problem. > > 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). -Tiru > > However, it does require that it be infeasible to find another > encapsulated key that decapsulates to the same shared secret under the > same key. But that is considered basic KEM security property. > > > > > -Ilari > > _______________________________________________ > 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]
