Hi Ilari The participants of the IETF#114 meeting expressed an opinion about the approach of how to encode the public key in a COSE message, namely to re-use the structures already defined. Those map nicely to what is being defined for HPKE in terms of algorithms as well. For PQC algorithms the work on these encodings is still ongoing and I am sure they will be re-usable as well. In terms of implementation effort, the biggest work is on implementing the PQC algorithm and the integration of it into HPKE not in the integration with COSE (where we are talking about a few lines of code only anyway).
I am waiting for the chairs to confirm the decision from the meeting to close this topic. Ciao Hannes -----Original Message----- From: COSE <[email protected]> On Behalf Of Ilari Liusvaara Sent: Thursday, August 25, 2022 5:27 PM To: [email protected] Subject: Re: [COSE] Next steps with COSE-HPKE .... was RE: HPKE: Ephemeral public key encoding On Thu, Aug 25, 2022 at 01:06:07PM +0000, Hannes Tschofenig wrote: > Hi Russ, Hi Ilari, > > At the IETF meeting the group wanted to go forward with the approach > of re-using existing definitions for ephemeral public keys. > Currently, the IANA registry has several entries already that allows > us to represent public keys in the following formats > > - NIST (P-256, P-384, P-521), > - X25519, and > - X448 > > This list corresponds to what is in the HPKE RFC. > > Other drafts will add further algorithms in the future and can easily > be utilized as well. Someone will have to write how those algorithms > work with HPKE and establish entries in the registry. The problem with above is that it does not define a generic mechanism to embed _any_ possible HPKE algorithm. This leads to spec writers and implementers to having to redo the work of adding a piece of HPKE into COSE for every new HPKE algorithm. With such generic mechanism, adding new algorithm is just defining the codepoint mappings. Or not even that with the "HPKE" kty. And the generic mechanism is the obvious way to add X25519 and X448. Secondary problem is that using X25519 and X448 codepoints in eph wastes space. I think COSE-HPKE should define the compact NIST curves for HPKE, and a generic mechanism to embed HPKE in COSE. Then the NIST curve special- case stuff can just be ripped out as obsolete. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose 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
