HPKE AAD for JWE Key Encryption

[OR13]

hpke-aad SHALL be the FixedInfo part of ECDH-ES Concat KDF input. That is,
concatenation of AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and
SuppPrivInfo inputs, in that order, as defined in section 4.6.2 of JWA.

https://mailarchive.ietf.org/arch/msg/jose/kGF-m5XJunr-M26USFyFeqYoSvw/

[ilaril]

Related, from the editor's copy:

Additionally, the same key MUST NOT be used for both key wrapping and content encryption, as it may introduce security risks.

This is problematic on several levels:

• If this practice introduces possible security risks, then JOSE-HPKE is flawed (cryptographic protocols are expected to not rely on operational practices where feasible).
• There are no JWK-level controls for this purpose. Integrated Encryption and Key Encryption use the same "alg" values on purpose. And JWK key_ops turns out to be totally busted.
• Forbidding this practice can be expected to cause significant operational issues.

This issue is related, because HPKE AAD for Key Encryption is significant for preventing any issues with mixing key wrapping and content encryption.

And some notes about fields used:

• AlgorithmID is not well-defined for Key Encryption. HPKE already binds its ciphersuite, so "alg" is redundant. However, using "enc" here would protect against bad implementations that allow unsafe bulk ciphers.
• SuppPubInfo contains key length, which is meaningless for HPKE.
• SuppPrivInfo is always empty.

Using len32(enc) || enc || len32(PartyUInfo) || PartyUInfo || len32(PartyVInfo) || PartyVInfo as aad for Key Encryption would guarantee safety of mixing key wrapping and content encryption (as nobody is going to use 1.5GB+ enc values).