Re: [jose] Std Java key representation of OKP in draft-liusvaara-jose-cfrg-curves-00

Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 05 January 2016 16:44 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593041A89B4 for <jose@ietfa.amsl.com>; Tue, 5 Jan 2016 08:44:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6Utn5iZj0hY for <jose@ietfa.amsl.com>; Tue, 5 Jan 2016 08:44:39 -0800 (PST)
Received: from p3plsmtpa06-10.prod.phx3.secureserver.net (p3plsmtpa06-10.prod.phx3.secureserver.net [173.201.192.111]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E17F1A1BA7 for <jose@ietf.org>; Tue, 5 Jan 2016 08:44:39 -0800 (PST)
Received: from [192.168.0.112] ([77.77.164.50]) by p3plsmtpa06-10.prod.phx3.secureserver.net with id 2Gkd1s00115ZTut01GkdHb; Tue, 05 Jan 2016 09:44:39 -0700
To: Anders Rundgren <anders.rundgren.net@gmail.com>, Ilari Liusvaara <ilariliusvaara@welho.com>
References: <00e001d13d1b$09519d50$1bf4d7f0$@augustcellars.com> <20151223064653.GA24022@LK-Perkele-V2.elisa-laajakaista.fi> <567A49F3.8050500@gmail.com> <20151224054643.GA25322@LK-Perkele-V2.elisa-laajakaista.fi> <567BCEB6.3040609@connect2id.com> <567BE989.8020800@gmail.com> <567C0338.50907@connect2id.com> <567C2285.4050109@gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <568BF2F4.1060808@connect2id.com>
Date: Tue, 05 Jan 2016 18:44:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <567C2285.4050109@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020403050402050809010303"
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/D94u0vLm7HpEzYX_PpZnjeCMCBU>
Cc: jose@ietf.org
Subject: Re: [jose] Std Java key representation of OKP in draft-liusvaara-jose-cfrg-curves-00
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2016 16:44:41 -0000

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
>>>> jose@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>
>>>
>>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose