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
