On Mon, Jul 11, 2022 at 11:27:07AM +0000, Hannes Tschofenig wrote:
> Hi Ilari,
>
> So you rely on the assumption that a P-256 curve will also be used
> with HKDF-SHA256?
My code does not assume this. It is just incidential that the only
KDF that can be paired with P-256 KEM (due to defined key types)
happens to be HKDF-SHA256.
The underlying HPKE code supports any combination of AEAD, KDF and
KEM. And the COSE code uses lookup table to translate crv values into
KDF and KEM to pass to HPKE.
> Regarding the key format I noticed that your P256 key format differs from
> what the group has been using so far.
>
> Here is what you have:
>
> > P256 public key:
> >
> >
> > {
> > 1: 1, / kty => OKP /
> > 2: h'1F677209D1C5174C', / Some random kid /
> > -1: -65537, / crv => -65537 (HPKE P256 with SHA256) /
> > / Raw public key data, 65 bytes /
> > -2:
> > h'040E271193AE34E989C5BDD36A8AF81391B62A2501A49203EA7511B5CC4E44A5753FAB35EA9E5FDEAF037E2B24CB1FF21C4C4AF1ED8AF3A91C4FECF69187DA4369'
> > }
>
> Here is what has been used in the group before (for example in key
> sets):
>
> {
> / kty / 1:2,
> / kid / 2: h'1F677209D1C5174C',
> / crv / -1:3,
> / x / -2:h'0072...85e5c8f42ad',
> / y / -3:h'01dc...fe1ea1d9475',
> },
>
> Couldn't we just use one format for expressing the public key?
My implementation supports just one format for long-term keys: The
uncompressed raw format, with HPKE-specific crv.
- Not having that would likely lead to mess with any new KEM. It is
much more difficult to add a new compressed key type than adding new
KEM with uncompressed raw key format.
- Keys like the above can be confused with standard ECC keys. Which is
cryptographically unsound.
What I would love is that HPKE added compact NIST curves, and then we
could just rip out the entiere point compression machinery as unneeded
complexity and use the raw format everywhere.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
