[Internet]"Pluggable" key serialization in JCE/JCA

[xueleifan(XueleiFan)]

> On Mar 23, 2022, at 11:46 PM, Anders Rundgren <anders.rundgren.net at 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”.

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
>