Should we be using OKP for the "kty"

[mprorock]

Key type could very well be OKP in this case and we should seriously consider it - group should get feedback in on this

[cyberphone]

I would very much recommend against overloading OKP because that breaks existing OKP software. OKP is fine but in the end you still have to convert it to the platform's own representation of keys. If you take Java, Oracle have after 5 years managed creating such interfaces for Ed25519/Ed448 and X25519/X448. These wont's change. Creating new Java key types is the way to go and can be done without external involvement.

I believe this applies to most platforms although the details differs.

An example showing the ugliness of existing OKP solutions due to the fact that Oracle never bothered with OKP: https://github.com/cyberphone/openkeystore/blob/master/library/src/org/webpki/crypto/OkpSupport.java

You have a chance creating more functional interfaces where Key, PrivateKey, and PublicKey for the respective algorithms have direct counterparts to their external representation, not requiring folks do ASN.1!

If possible (and applicable), I would at an early stage consider PKIX and PEM formats as well.

By having unique key types you also don't run into clashes with cryptographic providers. Crypto libraries will be able to see that this is an XYZ key which requires calling a special driver.

[OR13]

https://datatracker.ietf.org/doc/html/rfc8037#section-2

Basically, we can't use OKP because of the MUST for use with crv which is not relevant to us.

[cyberphone]

RFC 8037 also uses polymorphic (generic) signature algorithms which I once brought up as a mistake which much later was echoed by one of the COSE WG co-chairs.

RFC 8037 should IMO be regarded as "frozen" and dedicated to the four algorithms it is currently known to support. As such it works OK. Comparable definitions from the ASN.1/X.509 world have adopted an approach which separates algorithms classes from each other. This is compatible (albeit in a somewhat quirky way), with current COSE/JOSE definitions. Overloading existing definitions would break this compatibility as well as associated support code.

That is, even if a new crypto system has identical parameters to an existing ditto, it should get a separate name space in order to permit safe and simple integration in supporting libraries and APIs. In a "pluggable" crypto architecture, this could potentially be done without a touching a single line of code. The most recent version of OpenSSL supports pluggable crypto providers. The system used in Java could be fitted with integral support for JOSE/COSE keys without disrupting any of its current features. Eventually you could end-up with cool stuff like:

    KeyPair keyPair = new KeyTranslator().import(byte-array | stream);

You would not even have to specify if the key-pair is provided as PKCS #8/PEM, COSE, or JOSE since the basic format can be detected by simple "sniffing".

[OR13]

KeyPair keyPair = new KeyTranslator().import(byte-array | stream);

^ this is basically how multi codec works.

[OR13]

Latest draft does not suggest this, closing.