Looks to me that HPKE internally defines what “enc” should be. The formatting of “enc” is an internal HPKE issue. It happens to be a serialized public key produced by the HPKE SerializePublicKey() function, but no one but the HPKE libraries need to know that.
Why would any thing other than an HPKE library ever look inside “enc”? Seems like no reason, so there’s no reason to do anything but transport the bytes back and forth for HPKE libraries. I really don’t like the idea that a COSE-HPKE implementation would have to parse the “enc” returned from Seal() to turn it into a COSE_Key and then serialize it back into an “enc” to pass to Open(). Seems kind of an awful layering violation and unnecessary code. I don’t think there’s an interop problem here. I’m pretty confident that HPKE is well-built so that if you take what you get from Seal() and give it to Open() it will work. I am aligned with Ilari on this one so far. LL On Jul 14, 2023, at 10:04 AM, Orie Steele <[email protected]<mailto:[email protected]>> wrote: Here is an example of how different versions of HPKE might choose to encode `enc` with their favorite way to represent opaque bytes: https://gist.github.com/OR13/7d99f46c56e7f78082097452158125ef Coming from W3C where we see a lot of "new ways to represent opaque bytes of a (un?) known type"... I would expect at a minimum: Some people will use compressed EC points Some will use expanded EC points Some will use protocol buffers Some will use MultiKey (multi formats, multibase) Some will use XML Some will use YAML .... Some people will use JWK Some people will use COSE Key I think all of these are valid interpresentation of HPKE, and might have great use cases. None of them will be interoperable. I think: - JOSE should encode enc as a JWK, - COSE should encode it as a COSE Key This will improve interoperability. OS On Fri, Jul 14, 2023 at 11:23 AM lgl island-resort.com<http://island-resort.com/> <[email protected]<mailto:[email protected]>> wrote: 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 -- ORIE STEELE Chief Technology Officer www.transmute.industries<http://www.transmute.industries/> [https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
