Sounds like the current best option for HPKE single shot direct encryption
in JOSE would be:
{ alg: HPKE-....-A128GCM, enc: dir }
Which would require updating JWE, and this part of the IANA registry:
https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms
OLD:
dir Direct use of a shared symmetric key alg Recommended [IESG
<https://www.iana.org/assignments/jose/jose.xhtml#IESG>] [RFC7518, Section
4.5 <https://www.iana.org/go/rfc7518>] n/a
NEW:
dir Direct use of a shared symmetric key alg Recommended [IESG
<https://www.iana.org/assignments/jose/jose.xhtml#IESG>] [RFC7518, Section
4.5 <https://www.iana.org/go/rfc7518>] n/a
dir Direct use of a fully specified encryption suite enc Recommended [IETF]
TBD n/a
OS
On Tue, Jun 11, 2024 at 10:08 AM Ilari Liusvaara <[email protected]>
wrote:
> On Tue, Jun 11, 2024 at 07:55:48AM -0500, Orie Steele wrote:
> > A few questions for the group:
> >
> > Does HPKE require us to update JWE? Or can we use existing structures?
>
> Direct HPKE requires updating JWE, but indirect does not.
>
> The problem is that JWE always performs bulk message encryption, which
> conflicts with bulk message encryption in direct HPKE. JWE has no
> facility to suppress bulk message encryption.
>
> Indirect HPKE fits JWE definition of Key Encryption, so it works with
> JWE as is.
>
> Then JWE header and recipient handling has some quirks (there always
> is at least 1 recipient, and recipient headers are always unioned),
> and I think that one needs to be very careful about changing those
> due to potential of such changes to play hell with JWE
> implementations.
>
>
> (In COSE, bulk encryption is performed by whatever happens to be at
> layer zero, and anything capable of that can be made to be layer one
> under COSE built-in AEAD for multi-recipient operation. So direct
> versus indirect makes no difference, both work in unified way.)
>
>
> > Which of these is better for HPKE direct encryption with a single shot
> api:
> >
> > 1. { alg: HPKE-....-A128GCM, enc: A128GCM }
>
> JWE already defines what this means in manner incompatible with direct
> HPKE. So this can not work. Would be fine for indirect HPKE tho.
>
>
> > 2. { alg: HPKE-....-A128GCM, enc: HPKE }
>
> There was variant of this with enc:dir that better expresses what is
> going on. And had advantage of not requiring new registration, which
> might get prohibited by draft-ietf-jose-fully-specified-algorithms.
>
> And if enc:dir is required to be in protected headers, that would take
> out the crossmode attack.
>
>
> > 3. { alg: HPKE, enc: HPKE-....-A128GCM }
>
> This is not compatible with draft-ietf-jose-fully-specified-algorithms.
>
>
>
>
> -Ilari
>
> _______________________________________________
> jose mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
