> 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>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
