On 2015-12-24 15:37, Vladimir Dzhuvinov wrote:
On 24/12/15 14:48, Anders Rundgren wrote:
On 2015-12-24 11:53, Vladimir Dzhuvinov wrote:
Hi Ilari,
Thank you for making this new contribution to the JOSE suite.
The Java library for JOSE that I maintain includes methods for
converting
between JWK instances and the standard Java types for representing
keys.
My reading of the spec is that the established Java DHPublicKey
<https://docs.oracle.com/javase/7/docs/api/javax/crypto/interfaces/DHPublicKey.html>
/
DHPrivateKey
<https://docs.oracle.com/javase/7/docs/api/javax/crypto/interfaces/DHPrivateKey.html>
interfaces would be the best match for the proposed "OKP" JWK. Does
this make sense?
Hi Vladimir,
Is your goal to eventually make this a part of standard java?
For now I just want to figure out how these algs can be implemented in
Java, and if it's possible to do that in a way that fits established
interfaces, frameworks and conventions. The representation of the keys
is one aspect of that.
Making this part of standard Java is a serious commitment. I'm not ready
and qualified to go that far :) I'm not familiar with the standard
making process either.
I would be interested in cooperating on a OpenJDK contribution.
Regardless of that my experiences with named EC curves in Java
(without BouncyCastle installed) would speak against reusing DH*
since there is no place for "crv" (or whatever it will be called...)
and "x" is called Y.
https://docs.oracle.com/javase/7/docs/api/javax/crypto/spec/DHPublicKeySpec.html
I would therefore consider starting with a new key type (OKP*).
How would you name this?
I would name keys OKPPrivateKey and OKPPublicKey which in turn
would extend PrivateKey and PublicKey respectively as well as a new type OKPKey.
In Java, as opposed to JWK, the public and
private parts are represented separately. "octet" qualifies the
encoding,
The encoding is actually quite a problem since JCE [more or less] builds
on PKCS #8 for private keys and SPKI for public keys and these are not
(yet) standardized. Yes, the Java KeyStore won't work either until there
is a working PKCS #12 which I believe builds on PKCS #8 and X.509/SPKI.
However, using JWK you could create a public key like:
KeyFactory.getInstance("OKP").generatePublic(new OKPPublicKeySpec(curve, x));
where curve would be a String and x byte[]
Reusing DH may be possible but I think it creates more problems than it solves
:-)
OTOH, the more I think of it...I wonder if it is not better simply creating
concrete classes for OKPPublicKey and OKPPrivateKey rather than interfaces and
not bother about JCE at this early stage:
OKPPublicKey publicKey = new OKPPublicKey(curve,x);
if (myKey instanceof OKPKey) {
// run special code
} else {
// use JCE
}
Anders
and because of this I'm not sure it should be part of the
class name. EdCPublicKey / EdCPrivateKey? (EdC = Edwards-Curve)
If something "standard-ish" is the target, I would try to get some
feedback on an early proposal.
Regards,
Anders
The current JWK types map as follows:
* "OCT" JWKs map to / from javax.crypto.SecretKey
* "RSA" JWKs map to / from
java.security.interfaces.RSA{Public|Private}Key
* "EC" JWKs map to / from
java.security.interfaces.EC{Public|Private}Key
Can you recommend Java implementations of the new algs? I'm looking
for a good place to start in order to add support for them in JOSE.
Thanks,
Vladimir
--
Vladimir Dzhuvinov
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
