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. Ciao Hannes -----Original Message----- From: COSE <[email protected]> On Behalf Of Russ Housley Sent: Wednesday, July 27, 2022 7:34 PM To: Ilari Liusvaara <[email protected]> Cc: [email protected] Subject: Re: [COSE] HPKE: Ephemeral public key encoding Ilari: I now realize that I was not properly understanding your point or I was conflating it. The IANA registry for COSE Algorithms includes: X25519 4 OKP X25519 for use w/ ECDH only X448 5 OKP X448 for use w/ ECDH only For the algorithms, OKP would be used as indicated by the registry. Russ > On Jul 27, 2022, at 10:38 AM, Ilari Liusvaara <[email protected]> > wrote: > > On Mon, Jul 11, 2022 at 04:25:57PM +0000, Hannes Tschofenig wrote: >> Hi Ilari, >> >> I guess these are points that we should discuss at the IETF COSE >> meeting. >> > > Listened the part about COSE-HPKE in the meeting. > > > The discussion was about the special case of NIST curves. It did not > seem to discuss anything about the general case. > > * The general-case ephremeral keys are required by X25519 and X448. > * X25519 and X448 can already use general-case public keys. But the > next KEM after that, will probably require general-case public keys. > KYBER will be especially bad case. > * I consider this required for getting any sort of real advantage > from COSE HPKE. The spec currently adds no cryptographic capabilities > to COSE. It is more compact, but special-case compact ECDH-ES would > have been more compact still. However, next KEM HPKE adds will > probably bring new capabilities. > > > And the general case will be dumping raw octet string outputs from > HPKE. Ephemeral public keys. Public keys. Private keys. > > > > There are essentially two options here (after fixing the NIST special > case, as some options are incompatible with that). Both will easily > handle KYBER when HPKE adds it, or compact NIST if HPKE adds it: > > > 1) Use OKP new crv, Symmetric for EKs: > > { > 1: 1, / OKP / > 2: h'623FCA05CED1C293', / KID / > -1: TBD, / CRV COSE_CRV_HPKE_X25519_SHA256 / > / Raw public key from HPKE / > -2: h'56D7B1DEBC69B56EE457E518DB604EF60CF528A91E08B6326C112D9E886BC135' > } > > -1: { > 1: 4, / Symmetric / > / Raw encapsulated key from HPKE / > -1: h'F7A0E8EAAC3CA9A10E32FD7483C604C114D82E4944D22E267DFCB5AF43A9903E' > } > > > This is what my code does. 2 byte smaller public/private keys for > having to add new entry to registry for each new KEM. > > > 2) Use new KTY with explicit KEM/KDF in PK: > > { > 1: TBD, / KTY HPKE / > 2: h'623FCA05CED1C293', / KID / > -1: 32, / DHKEM(X25519, HKDF-SHA256) / > -2: 1, / HKDF-SHA256 / > / Raw public key from HPKE / > -3: h'56D7B1DEBC69B56EE457E518DB604EF60CF528A91E08B6326C112D9E886BC135' > } > > -1: { > 1: TBD, / KTY HPKE / > / Raw encapsulated key from HPKE / > -3: h'F7A0E8EAAC3CA9A10E32FD7483C604C114D82E4944D22E267DFCB5AF43A9903E' > } > > > Having new KEMs added to HPKE be immediately usable for 2 byte larger > public/public keys. > > > > And about "overloading" OKP to non-curves, RFC 8037 _explicitly_ says > OKP does apply to non-curves (the "crv" naming is bad). > > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ 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
