"Pluggable" key serialization in JCE/JCA

[Michael StJohns]

On 3/24/2022 2:46 AM, Anders Rundgren 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?

Hi Anders -

Isn't that the exact purpose for KeyFactory and its plugins?

You might need to add KeySpec types for Jose and Cose 
(JOSEEncodedKeySpec and COSEEncodedKeySpec) assuming both of those cover 
all of the secret, public and private key specifications.

Or hmm... GenericEncodedKeySpec (String alg, byte[] encoded key) or 
GenericEncodedKeySpec (String alg, String encodedKey).


>
> 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".

Nope.  This isn't safe as someone might up with yet another 
representation that looks like one of the "sniffable" ones.  You could 
build a private implementation that takes its best shot, but ....

>
> 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.

Again, no.  Don't do this in an incomplete way - it will come back to 
bite you.  You don't have to implement the plugin that talks to the HSM, 
but you have to define the mechanism/API so that the HSM vendors don't 
curse your first born child later.

Mike


>
> WDYT?
>
> Thanx,
> Anders