> On Mar 11, 2022, at 11:11 AM, Ilari Liusvaara <[email protected]>
> wrote:
>
> On Fri, Mar 11, 2022 at 05:23:48AM +0100, Anders Rundgren wrote:
>> Before deciding to overload "OKP" for a new crypto system, I would discuss
>> the matter with maintainers of cryptographic libraries and APIs.
>>
>> In the Java platform overloading the native counterparts to OKP keys
>> [1,2] won't happen because that would break a lot. I guess the same
>> is valid for OpenSSL.
>
> The way it is supposed to work is to use the raw key parts as key
> material in underlying cryptographic implementation. Implementations
> where that is not possible are just broken.
>
>> It seems to me that reusing OKP would rather create an artificial
>> "semantic gap" which doesn't exist today where "kty" indeed is
>> synonymous with key type/family (RSA, EC, Ed etc):
>> https://datatracker.ietf.org/doc/html/rfc7517#section-4.1
>
> There are already two "subtypes" of OKP keys that are not
> interchangeable:
>
> - Key agreement keys.
> - Signature keys.
>
> NISTPQC signatures would fit into signature keys "subtype", but NISTPQC
> KEMs will not fit into the key agreement keys "subtype", so that would
> be a third "subtype" (all NISTPQC algorithms have OKP-style key format,
> as this was required by NIST).
Right. It makes sense to add support for KEM. We can figure that out without
waiting for NIST to announce Round 3 winners. We can do the work based on RFC
5990.
Russ
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
