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
