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
