Re: [jose] HPKE PartyU / PartyV

[Neil Madden <[e-mail]>]

From a JOSE point of view, I would ignore them. I have used these fields, but only to put a hash of the public keys into to ensure non-malleability and proper identity binding. HPKE already does that. IMO it would be nice if JOSE had a way to inject such contextual information *without* putting it in a header, but it is what it is. 

PS - I’m not sure how useful it is to cross-post these questions to both JOSE and COSE groups. In my experience, they are very different standards, with very different use-cases. 

— Neil

On 27 Feb 2024, at 20:03, Orie Steele <[e-mail]> 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...

JOSE has this to say: https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.1.2" rel="nofollow">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.
"""

COSE has this to say: https://datatracker.ietf.org/doc/html/rfc9053#name-context-information-structu" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc9053#name-context-information-structu

(TLDR... No MUST).

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.

HPKE has support for enabling this consistently, and JOSE and COSE have the structures we need to use, already defined.

My question is not if we can do this, it is SHOULD we do this....

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

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

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

Regards,

OS

--

ORIE STEELE
Chief Technology Officer
www.transmute.industries

https://transmute.industries" target="_blank" rel="nofollow">https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc">

_______________________________________________
jose mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jose