Hi Guys,
May I as an implementer also comment on the idea of overloading the OKP
identifier?
Actual code for a COSE public key decoder:
// Throws an exception if there is no KTY label (=key object is completely
malformed).
int coseKty = publicKeyMap.getObject(COSE_KTY_LABEL).getInt();
KeyTypes keyType = keyTypes.get(coseKty);
if (keyType == null) {
throw new GeneralSecurityException("Unrecognized key type: " + coseKty);
}
I guess that most decoders do something like this since the parameters associated with
each "kty" are quite different.
If you OTOH overload OKP, decoders would assume that they are going to process
an x25519, x448, ed25519, or ed448 key and convert these to the platform's own
representation. Such code will fail and in a much less predictive way. BTW,
Oracle would never considering extending their existing interfaces for the
mentioned algorithms; they would define new ones. Some people suggested
retrofitting the EC interfaces for ed25519 and friends but Oracle turned down
this request since existing crypto providers would either have to be upgraded
or just crash and that is not overly appealing. Clean separation is more
important than code reuse. A key decoder/encoder is also a very small piece of
code.
This is also a question about adoption. By using different identifiers,
software can be upgraded without support by the platform vendors. It took
Oracle 5 years to introduce native support for Ed25519!
Cheers,
Anders
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
