Correct. The HPKE library would produce "enc" in some format, and then COSE should just transmit it unmodified.
On Fri, Sep 30, 2022 at 10:19 AM Orie Steele <[email protected]> wrote: > That includes not touching `enc` in the case that the HPKE library decided > to use multibase keys... right? > > If I wanted to make an HPKE with multibase keys library for DHKEM for > example. > > OS > > On Fri, Sep 30, 2022 at 9:16 AM Richard Barnes <[email protected]> wrote: > >> I think you have me backwards, Orie. "Opaque bytes" doesn't mean "COSE >> gets to define what goes in here", it means "COSE needs to take what the >> HPKE library gives it and not touch it". >> >> On Fri, Sep 30, 2022 at 9:58 AM Orie Steele <[email protected]> >> wrote: >> >>> > I'm saying it's not up to this group to decide what the opaque bytes >>> mean. (That's what it means for them to be opaque!) >>> >>> ^ Strongly agree with this. >>> >>> I interpret this as a direct invitation to embed arbitrary data in >>> "opaque bytes"... including alternative key representations, or COSE Key. >>> >>> IMO the test vectors missed an opportunity to recommend COSE Key for >>> DHKEM... and it will lead to less adoption of COSE Key for use with HPKE. >>> >>> OS >>> >>> >>> >>> On Fri, Sep 30, 2022 at 8:51 AM Richard Barnes <[email protected]> wrote: >>> >>>> I'm not saying any of that. I'm saying it's not up to this group to >>>> decide what the opaque bytes mean. (That's what it means for them to be >>>> opaque!) This group is defining how to carry HPKE's data between a sender >>>> and a receiver, so the definition that matters is HPKE's. >>>> >>>> By way of analogy: Lots of systems put meaningful, structured stuff in >>>> the AAD input to AEAD encryption. But the AEAD interface (e.g., in RFC >>>> 5116) defines AAD to be opaque bytes, so that's how JWE treats it. Because >>>> JWE is carrying the AEAD's data from a sender to a receiver, so the >>>> definition that matters is the AEAD's. >>>> >>>> >>>> On Thu, Sep 29, 2022 at 2:12 PM Orie Steele <[email protected]> >>>> wrote: >>>> >>>>> If `enc` is opaque... you can't say that some future PQC system won't >>>>> use it to encode a public key... right? >>>>> >>>>> Are we saying that there will never be a PQC (or other) system that >>>>> works with HPKE that looks like DHKEM? >>>>> >>>>> It looks to me like we can't have it both ways... if it's opaque, >>>>> we're allowed to make it whatever we want... If it's a COSE Key, it has to >>>>> play by those rules. >>>>> >>>>> OS >>>>> >>>>> >>>>> On Thu, Sep 29, 2022 at 12:14 PM Richard Barnes <[email protected]> wrote: >>>>> >>>>>> I know, and that's exactly what I'm saying will cause problems if you >>>>>> treat "enc" as a key. Because it is not a key in those algorithms. >>>>>> >>>>>> On Thu, Sep 29, 2022 at 10:48 AM Hannes Tschofenig < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> My point is that it is very likely that someone will want to >>>>>>> introduce PQC algorithms in COSE as well. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ciao >>>>>>> >>>>>>> Hannes >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* Richard Barnes <[email protected]> >>>>>>> *Sent:* Thursday, September 29, 2022 3:54 PM >>>>>>> *To:* Hannes Tschofenig <[email protected]> >>>>>>> *Cc:* [email protected] >>>>>>> *Subject:* Re: [COSE] COSE_Key for HPKE encapsulated key >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> -- >>>>> *ORIE STEELE* >>>>> Chief Technical Officer >>>>> www.transmute.industries >>>>> >>>>> <https://www.transmute.industries> >>>>> >>>> >>> >>> -- >>> *ORIE STEELE* >>> Chief Technical Officer >>> www.transmute.industries >>> >>> <https://www.transmute.industries> >>> >> > > -- > *ORIE STEELE* > Chief Technical Officer > www.transmute.industries > > <https://www.transmute.industries> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
