Hi Mike & the JDK crypto team,
What I'm saying is that key serialization in Java haven't gotten enough
attention. Examples:
AFAIK, there is still no support for using named curves to construct an EC key.
Names curves are MANDATORY in JOSE/CODE.
The gap between EdDSA keys as expressed in JOSE/COSE and the Java API is simply
put GIGANTIC:
https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022379.html
The only obvious solution is rolling your own:
https://github.com/cyberphone/openkeystore/blob/master/library/src/org/webpki/crypto/OkpSupport.java
This code [probably] stinks but it is hardly my fault...
The JDK crypto team is the only party who can clean up this mess.
Since importing X.509 certificates through PKCS12/KeyStore works out of the box
without any a prior knowledge of key algorithms, there is already a precedent.
It is almost just copy and paste :)
The new crypto systems that are on the way in (BLS, Post Quantum), accentuates
this issue.
Regarding HSMs, I gave it one more thought and I didn't come up with any
connections except maybe in Keytool but HSMs appear to be X.509-oriented which
not the case with COSE/JOSE.
Regards,
Anders
On 2022-03-25 3:12, Michael StJohns wrote:
On 3/24/2022 12:28 PM, Anders Rundgren wrote:
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?
Um - no. They presume you know the key algorithm, but (using EC Public
keys for example), you can use either of the X509PublicKeySpec (to
decode an encoded key), or the ECPublicKeySpec (to deal with building a
key from scratch using the parameters. You can notionally (haven't
tried it, but should work) use KeyFactory.getKeySpec() to convert
between the two formats or use Key.getEncoded() to get the default
encoding for the key.
The equivalent on the ECPrivateKey side are the ECPrivateKeySpec and
PKCS8EncodedKeySpec clases.
PEM is actually not an encoding, but a wrapping of an encoding. The only
part of Java that deals with it natively (I believe) is the
CertificateFactory for X.509 certificates. You may have an extra step
to add or remove a PEM style envelope (or the equivalent BASE64 bare
string), but that's reasonable.
The requirement to know key algorithm in advance forces you into ASN.1
decoding for dealing with PEMs. Been there done that.
Ah - not sure why you wouldn't know the key algorithm, BUT: It should
theoretically be possible to write a KeyFactory provider that does that
decoding for you from the X509PublicKeySpec (or PKCS8PrivateKeySpec) and
returns an appropriate PublicKey. Check the actual return type to figure
out what type of key. E.g.:
KeyFactory kf = KeyFactory.getInstance("GenericDecoder");
As I said below, you'll need to define the equivalent opaque format
KeySpec classes to handle COSE and JOSE. I think that's a class per
type of encoding.
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.
It's trivial NOW because its a closed set of possibilities. And even
then, you're assuming you don't have to detect ASN1 vs raw key encodings
vs string encodings. Simply detecting a) whether a file is character,
b) detecting the character encoding, and c) accidentally thinking a
character file is actually binary or vice versa is fragile.
The addition of the "new" EC variant keys required a substantial
reworking of the API to support them and the arguments were fierce. The
additions were not free.
I deal with no fewer than 3 encodings for an EC public key. Two or
three for an EC private key. 2 or 3 text versions of a RSA public key
along with the X509Encoded binary version and the TPM binary version.
Etc. I usually know what type of key I'm dealing with when I get it,
but I would love a magic DWIM class that did the right thing on all inputs.
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.
This is the problem with open source some times. It may be core, but it
is not complete and leaving this as a problem to be worked later is a
bit unprofessional.
I don't mean any offense here, but there's a problem with basing
everything what IOT requires and ignoring everything else.
Later, Mike
Anders
Mike
WDYT?
Thanx,
Anders
