On Wed, Sep 28, 2022 at 2:28 PM Orie Steele <[email protected]> wrote:
> Thank you for your reply and links. > > > It is **coincidentally** a serialized public key with DHKEM. > > How do I produce a "serialized public key" as an "opaque byte string" > given a public key in JWK / COSE_Key format, say for example I already have > a P-256 Public Key....? > > In the case of P-256 for example, does HPKE assume a compressed or not > compressed public key for the "opaque byte string". > My point is that you as a COSE implementer should not have to know the answers to any of these questions. When you send, you should take the opaque byte string that your HPKE library produces and put it in a slot in the COSE object. When you receive, you should grab an opaque bytestring from a slot in the COSE object and put it in the "enc" input to your HPKE library. If you're doing anything more than that, you're doing unnecessary work and inviting bugs. --RLB > > Thanks in advance, > > Regards, > > OS > > On Wed, Sep 28, 2022 at 12:59 PM Richard Barnes <[email protected]> wrote: > >> Hi all, >> >> It was brought to my attention that this working group is considering >> representing the "enc" output of HPKE as a COSE_Key as opposed to an opaque >> byte string [1]. >> >> This is a category error and a bad idea. HPKE defines the encapsulated >> key to be a byte string. It is **coincidentally** a serialized public key >> with DHKEM. All the HPKE libraries I could find correctly produce an >> opaque byte string for the "enc" output: >> >> Reference implementation: >> https://github.com/cisco/go-hpke/blob/master/hpke.go#L382 >> Chrome/BoringSSL: >> https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/hpke.h#213 >> Firefox/NSS: >> https://searchfox.org/mozilla-central/source/security/nss/lib/pk11wrap/pk11hpke.c#41 >> Webex/MLSpp: >> https://github.com/cisco/mlspp/blob/main/lib/hpke/include/hpke/hpke.h#L198 >> >> Representing the "enc" output as anything other than opaque bytes is a >> mistake. It would require the COSE implementation to parse the "enc" >> output, causing a bunch of unnecessary work and inviting error. (If you >> want to represent it as opaque bytes plus some metadata, sure. But But >> don't parse it.) >> >> I'm not sure which of the chairs' options that maps to, but both the >> COSE_Key and Ilari's OKP proposal look incorrect to me, because they both >> imply that the value is a key. I think Daisuke Ajitomi's proposal is >> closer to correct. In any case, I hope this helps clear things up. >> >> --Richard >> >> [1] >> https://mailarchive.ietf.org/arch/msg/cose/qzYaUCkogRSt53A3oCaTe-IwQDI/ >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose >> > > > -- > *ORIE STEELE* > Chief Technical Officer > www.transmute.industries > > <https://www.transmute.industries> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
