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 """ 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 (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>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
