Thinking though this a whole lot more I think I was confused on which alg/enc parameters were used in which header elements. To avoid that confusion for myself, I'll refer to them using their RFC 7516 names:
Currently with JWE, `enc` algorithms/IDs are all AEAD algorithms, and I think this must remain the same. Consistency, no surprises, everything stays the same, lowest possible impact to all existing JOSE implementations. And actually, having this value be anything other than an AEAD algorithm would violate RFC 7516, Section 4.1.2 <https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.2> as written: "This algorithm MUST be an AEAD algorithm with a specified key length." Many implementations (mine included) make plenty of assertions that this must be an AEAD algorithm that requires secret keys, etc. Changing this to be a different type of algorithm would cause a lot of problems on implementations, especially those written in typesafe languages. In the multi-recipient case, I agree, there doesn't need to be an `enc` value in the JWE Per-Recipient Unprotected Header because it's always implied by the JWE Protected Header. This must be the same for all recipients anyway. Nor is an JWE Protected Header `alg` value required since that will likely be different per recipient. The union (JWE JOSE Header) for a single recipient and/or JWT must have both header parameters however. For HPKE then, it seems that the `alg` value only needs to include the first 2 HPKE cipher suite IDs/tokens and exclude the trailing AEAD id as Michael Jones said. But then Ilari said: "- The first means to use algorithm "HPKE-P256-SHA256" (presumably Direct Key Agreement) to derive key for "A128GCM" (which is defined by RFC7518) bulk encryption." I'm probably missing something, but I don't believe this is an issue. HPKE does not use nor accept direct shared symmetric key IKM (input key material). That is, HPKE is only to be used for public key derivation of a shared secret (KEM) which is then tied to context and made cryptographically uniform (HKDF), and that output key is used as the AEAD symmetric key. That means if you have an `enc` value, you only need the HPKE ID trailing tokens to be a tuple because you already have the 3rd in the `enc` header parameter. That is: header['alg'] + header['enc'] would always equal "HPKE-<KEMID>-<HKDFID>-<AEADID>" That is unless you're trying to use HPKE as a key encryption/wrapping algorithm, which brings me to my next question: Why is JWE HPKE Key Encryption necessary at all? Since HPKE requires asymmetric keys to be used, what is the use case for encrypting a direct/shared symmetric key when the recipient must decrypt with their private key anyway? Thanks, Les
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
