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

Reply via email to