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). This is very different from RSA and EC2, where there are no subtypes, and all keys are interchangeable. Another place similar multi-subtype non-interchangeable keys are seen is symmetric algorithms, as there are at least two "subtypes": - AE(AD) Encryption keys. - MAC keys. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
