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
- [jose] Comments on draft-liusvaara-jose-cfrg-curv… Jim Schaad
- Re: [jose] Comments on draft-liusvaara-jose-cfrg-… Anders Rundgren
- Re: [jose] Comments on draft-liusvaara-jose-cfrg-… Ilari Liusvaara
- Re: [jose] Comments on draft-liusvaara-jose-cfrg-… Ilari Liusvaara
- [jose] Std Java key representation of OKP in draf… Vladimir Dzhuvinov
- Re: [jose] Std Java key representation of OKP in … Anders Rundgren
- Re: [jose] Std Java key representation of OKP in … Vladimir Dzhuvinov
- Re: [jose] Std Java key representation of OKP in … Anders Rundgren
- Re: [jose] Std Java key representation of OKP in … Vladimir Dzhuvinov