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. 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 It is important to early on bring issues like this to a wider audience so we don't repeat the oddities we have seen in FIDO/COSE where EC signatures have different encodings and Ed25519 algorithm identifiers have different meanings. Thanx, Anders 1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/interfaces/EdECKey.html 2] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/interfaces/XECKey.html _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
