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
