"Pluggable" key serialization in JCE/JCA

[Anders Rundgren]

On 2022-03-24 16:59, Michael StJohns wrote:
> 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 -

Hi Mike,

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

They presume that you know not only the key algorithm but the associated parameters as well.  Why should users or library developers have to deal with that?

The requirement to know key algorithm in advance forces you into ASN.1 decoding for dealing with PEMs.  Been there done that.

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

Finding out if the container is COSE, JOSE, or PEM is (AFAICT) trivial.  If the guess is incorrect a properly designed decoder should simply fail.

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


This is little bit out of my league but targeting the masses is core.


Anders

> 
> Mike
> 
> 
>>
>> WDYT?
>>
>> Thanx,
>> Anders
> 
>