The "enc" outputs aren't public keys for PQ algorithms, though. Don't get mixed up.
On Thu, Sep 29, 2022 at 9:45 AM Hannes Tschofenig <[email protected]> wrote: > It is highly likely that people will define public key formats for all PQC > algorithms. Hence, the same issue will surface there as well. > > > > The point compression was something Ilari brought up and less interesting > to me. > > > > *From:* COSE <[email protected]> *On Behalf Of * Richard Barnes > *Sent:* Thursday, September 29, 2022 3:35 PM > *To:* Hannes Tschofenig <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [COSE] COSE_Key for HPKE encapsulated key > > > > Hey Hannes, > > > > What you are saying is only true with HPKE used with ECDH, not HPKE in > general (e.g., with Kyber). If you design a COSE thing that treats "enc" > as a public key, then it will only apply to ECDH, not HPKE in general. > > > > To the point (heh) about point compression: Whatever the HPKE mechanism > is, it's going to need a way to specify the public-key algorithm. If you > wanted to declare a public key algorithm that was effectively, "P-256 but > you translate the 'enc' value to a compressed point", that would be fine, > since (1) that's scoped to a specific algorithm and (2) it leaves the HPKE > logic unchanged, it just adds a compress/decompress step. > > > > --RLB > > > > > > On Thu, Sep 29, 2022 at 5:34 AM Hannes Tschofenig < > [email protected]> wrote: > > Hi Richard, > > > > there are already structures in COSE for describing a public key. The > information HPKE exposes is a public key (plus other things). > > > > Hence, the question is therefore: How many ways do we need to encode > public keys in COSE? > > > > The reason for proposing this document to the group was the use case we > had in SUIT. SUIT is about firmware updates for IoT devices. The HPKE > libraries you list below are probably written for Web use cases. Here is > the library I have been working on: > > https://github.com/Mbed-TLS/mbedtls/pull/5078 > > > > If you think the output of the pseudo HPKE API should also be sent over > the wire then the HPKE RFC maybe should not have said that it does not > define a wire protocol. > > > > Ciao > > Hannes > > > > *From:* COSE <[email protected]> *On Behalf Of *Richard Barnes > *Sent:* Wednesday, September 28, 2022 7:59 PM > *To:* [email protected] > *Subject:* [COSE] COSE_Key for HPKE encapsulated key > > > > 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/ > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
