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 < [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]> > 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: > > > > On Jul 14, 2023, at 8:13 AM, Tschofenig, Hannes < > [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 <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
