Re: [jose] [COSE] HPKE PartyU / PartyV

[Ilari Liusvaara <[e-mail]>]

On Tue, Feb 27, 2024 at 02:02:16PM -0600, Orie Steele wrote:
> Hello OSE-Enthusiasts,
> 
> As we align JOSE and COSE drafts for adding support for HPKE, we've
> encountered our old friends:
> 
> PartyU and PartyV...

Those two only really make sense for ECDH-SS. JOSE does not support
that at all, nor does HPKE (auth mode is not ECDH-SS).

 
> JOSE has this to say:
> https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.1.2
> 
> """
>    The "apv" (agreement PartyVInfo) value for key agreement algorithms
>    using it (such as "ECDH-ES"), represented as a base64url encoded
>    string.  When used, the PartyVInfo value contains information about
>    the recipient.  Use of this Header Parameter is OPTIONAL.  This
>    Header Parameter MUST be understood and processed by implementations
>    when these algorithms are used.
> """

Note that is only for key agreement algorithms. HPKE is not a key
agreement algorithm.

Now, native KEM support would be key agreement algorithm and would
process "apv" just like ECDH-ES does.


> COSE has this to say:
> https://datatracker.ietf.org/doc/html/rfc9053#name-context-information-structu
> 
> (TLDR... No MUST).

Every field in that structure seems to be at least one of:

- Redundant (e.g., AlgorithmID)
- Absurd (e.g., keyDataLength)
- Unsafe (e.g., PartyUInfo.identity)
- Non-interoperable (e.g., Party*Info.other)


The design philosophies of JOSE and COSE are rather different. JOSE is
designed to be interoperable and implementable without profiling. COSE
is designed to be heavily profiled down for application, and is not in
general meant to be interoperable nor implementable.

This already shows in KDF context structures. The JOSE one is 
interoperable, the COSE one is explicitly not interoperable.

Then there is plenty of stuff in COSE that is in theory interoperable,
but no implementation implements it. E.g., ECDH-ES with AES-GCM key
wrapping (bonus points for also using iv-generation).


> We have an opportunity to maintain parity here, and essentially
> repeat the support for behavior we have in JOSE and COSE for
> "ECDH-ES+A128KW", when PartyU and PartyV are present.

As stated above, PartyU and PartyV don't really make sense here.


> I've always found this part of encryption in JOSE troublesome, why is it
> necessary for HPKE to support this?

I don't think there is any good reason to support it. Especially with
the HPKE limitations on parameters.


> Are we passing up an opportunity to simplify things and remove an
> unused/underutilized feature from being required in a new, and currently
> not used encryption scheme (HPKE).

The simplest thing to do is to just ignore that stuff.


> Is it time for apu and apv to be ignored when present and not
> understood?

As explained above, the MUST is inapplicable. Thus "apu" and "apv"
are ignored for HPKE.




-Ilari