On 2022-03-24 17:27, xueleifan(XueleiFan) wrote:
On Mar 23, 2022, at 11:46 PM, Anders Rundgren <anders.rundgren....@gmail.com>
wrote:
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".
If I understand the proposal correctly, it may be challenging in the current
JCA/JCE framework, especially for interoperability, unless one just wants to
work with one provider only. A third provider need to understand the private
key spec so that it can work with it. It may be doable by defining the export
method accordingly, but again it will run into the problem you concerned about
“converting the keys back-and-forth”.
The idea is that each provider would also have a converter for the algorithms it support.
This is what I meant with "pluggable". If you want to use a specific provider
you would specify that as well.
Thanx,
Anders
Xuelei
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
