It’s a byte string, not a structure or integer or such where the on-the-wire format might vary. In this case it doesn’t matter that HPKE is not an on-the-wire format because there’s no ambiguity in how to convey a byte string, particularly in COSE.
Here’s the definition of HPKE Seal. def Seal<MODE>(pkR, info, aad, pt, ...): enc, ctx = Setup<MODE>S(pkR, info, ...) ct = ctx.Seal(aad, pt) return enc, ct enc works the same as ct (ciphertext)— just some bytes that are output by Seal() and conveyed via COSE to Open(). Nothing in the COSE infrastructure needs to look inside either of them. I strongly suspect that every HPKE library will produce and consume the same exact byte string. Seems like HPKE would be very broken if that wasn’t true. This just seems like internal HPKE stuff to me -- the details to implement a particular COSE algorithm. It’s fine for individual COSE algorithms to have stuff in their own opaque format. I don’t see it as the same class of issue as algorithm identification. I don’t feel much of a need to argue one side or the other here. LL On Jul 14, 2023, at 8:59 AM, Hannes Tschofenig <[email protected]<mailto:[email protected]>> wrote: We started with a COSE_Key representation for the enc output, see https://mailarchive.ietf.org/arch/msg/cose/K8W5LBXjmPqsmSFO-RdbOh8hlUI/ https://mailarchive.ietf.org/arch/msg/cose/kI10B-xaIUFTeN2lZNXKsgYBMSs/ Then, we went into the domain of - is it efficient: https://mailarchive.ietf.org/arch/msg/cose/zg-PfuD2uUi_YgrOJ11wFpGiBbw/ - what does the HPKE RFC really mandate regarding the wire format: https://mailarchive.ietf.org/arch/msg/cose/OQw-PQ_SgZDUGoolwCFuYffy61Y/ Since it was only me discussing with Ilari and Daisuke, I lost the argument: https://mailarchive.ietf.org/arch/msg/cose/oI_cRYbxTEo2Uwn7aXQV0dCmYtA/ Ciao Hannes Am 14.07.2023 um 17:39 schrieb lgl island-resort.com<http://island-resort.com>: On Jul 14, 2023, at 8:13 AM, Tschofenig, Hannes <[email protected]<mailto:[email protected]>> wrote: Hi Laurence, the problem is that the enc is currently an opaque blob where the format is determined by the implementation of the selected library. This means that there is zero interoperability between different implementations unless they happen to produce the same encoding. I see this as a problem. Well, yeah it has to interoperate. Isn’t enc defined by RFC 9180 and doesn’t that give interop? As long as all HPKE libraries produces / consume the same thing… Seems to me that it can be something HPKE-specific as long as it interoperates. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
