Hi Anders,

On 24/12/15 18:51, Anders Rundgren wrote:
> 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
> }

I wasn't aware that so many things remain to be sorted out in JCE. If
that's case then JCE can be retrofitted at a later stage, as you say.
Putting together a working JOSE implementation has a higher priority for
the mission of this WG. I already looked at some code, and will try to
go a step further on the next iteration, e.g. by implementing the key
generation.

Cheers,

Vladimir




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



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to