Inline: On Fri, Jul 14, 2023 at 1:09 PM lgl island-resort.com <[email protected]> wrote:
> 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”? > Exactly, and since it's "opaque"... such a library can output whatever it likes... possibly randomly alternating between valid opaque representations.... > Seems like no reason, so there’s no reason to do anything but transport > the bytes back and forth for HPKE libraries. > > Indeed, but what do the bytes represent, and how do you know that 2 HPKE libraries chose the same representation? > 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. > See above. > > 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. > > If every HPKE implementation produces the exact same structures this is true?... but since the bytes are opaque, how can we know? Would it not be legal to transform those opaque bytes internally before exposing them as opaque externally (compressing / decompressing, etc...) ? etc... Maybe this does not matter, in which case the challenge resolves to... how do you send opaque bytes in JOSE and COSE consistently, which seems solvable. I am aligned with Ilari on this one so far. > > LL > > > On Jul 14, 2023, at 10:04 AM, Orie Steele <[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 < > [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/> > > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
