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.
> 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.
> 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 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.
> > 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 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.
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]
