The intention of https://www.ietf.org/archive/id/draft-ietf-cose-post-quantum-signatures-00.html
Is to cover the key and signature formats for JOSE and COSE for: - Dilithium - Falcon - Sphincs+ AFAIK none of them are compatible with HPKE, and we only intended to register new signature `alg` values. We had at one point considered defining a COSE / JOSE key format for kyber. AFAIK there is no active work item at IETF to define Kyber keys for use in JOSE / COSE / HPKE. IMO, the spec that defines the `alg` should also mention the key formats that `alg` is known to be supported by, or included in. HPKE work is obviously further along than the PQC Signatures work, I assumed HPKE would define the key formats for any new keys that were used with its defined `alg` values. I was surprised to hear that HPKE works with Kyber, and not see any test vectors here: https://www.rfc-editor.org/rfc/rfc9180.html#name-test-vectors As a developer, I like test vectors for crypto systems that include public and private key representations, for example: https://www.rfc-editor.org/rfc/rfc7520#section-3.1 Happy to support this work, in whatever way seems best. If the WG wants us to add a Kyber COSE Key representation to draft-ietf-cose-post-quantum-signatures I can raise it on our next editors call. Regards, OS On Fri, Sep 30, 2022 at 3:48 AM Hannes Tschofenig <[email protected]> wrote: > In that case my worry is even more justified. > > > > Ciao > > Hannes > > > > PS: I think the title of draft-ietf-cose-post-quantum-signatures should > change since it contains more than just PQC signatures. > > > > *From:* Mike Jones <[email protected]> > *Sent:* Thursday, September 29, 2022 5:35 PM > *To:* Hannes Tschofenig <[email protected]>; Richard Barnes < > [email protected]> > *Cc:* [email protected] > *Subject:* RE: [COSE] COSE_Key for HPKE encapsulated key > > > > [Chair hat on] > > > > I’ll note that the COSE working group is already the party defining > post-quantum algorithm representations for COSE (and JOSE). See the > working group draft > https://www.ietf.org/archive/id/draft-ietf-cose-post-quantum-signatures-00.html > . > > > > -- Mike > > > > *From:* COSE <[email protected]> *On Behalf Of *Hannes Tschofenig > *Sent:* Thursday, September 29, 2022 7:48 AM > *To:* Richard Barnes <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [COSE] COSE_Key for HPKE encapsulated key > > > > 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. > 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>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
