"Pluggable" key serialization in JCE/JCA
Anders Rundgren
anders.rundgren.net at gmail.com
Thu Mar 24 06:46:46 UTC 2022
Hi List,
I find it a bit strange that every user of crypto either have to write or install specific software for converting JOSE/COSE/PEM keys back-and-forth to Java's internal representation. This reduces the value of the abstract types as well.
Now there is whole bunch of new algorithms coming to the Java platform making this task even less attractive.
So my question is simply: How about including this part in an enhanced JCE/JCA? That is, making the encoder/decoder "pluggable" and hiding this complexity from users and library developers?
Eventually you could end up with something like:
PrivateKey privateKey = new KeyConverter().readPrivateKey(byte[] or stream);
You would not even have to know in which format the key is supplied in since this could be accomplished by simple "sniffing".
To make "pluggability" feasible, I'm trying to convince the JOSE/COSE folks to give each new crypto system a separate namespace as an alternative to overloading OKP (RFC 8037), even if the parameters match technically. AFAICT, X.509 public keys essentially already adhere to this notion.
I would exclude private key import and export in HSMs since these are specific and rare occasions.
WDYT?
Thanx,
Anders
More information about the security-dev
mailing list