Re: [jose] CFRG ECC in JOSE - thumbprint

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 11 November 2015 08:37 UTC

Return-Path: <ilariliusvaara@welho.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 96D731A6F83 for <jose@ietfa.amsl.com>; Wed, 11 Nov 2015 00:37:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 PwCZDKG2_x_q for <jose@ietfa.amsl.com>; Wed, 11 Nov 2015 00:37:54 -0800 (PST)
Received: from filtteri5.pp.htv.fi (filtteri5.pp.htv.fi [213.243.153.188]) by ietfa.amsl.com (Postfix) with ESMTP id 728951A6F67 for <jose@ietf.org>; Wed, 11 Nov 2015 00:37:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by filtteri5.pp.htv.fi (Postfix) with ESMTP id 8AB865A76AB; Wed, 11 Nov 2015 10:37:35 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri5.pp.htv.fi [213.243.153.188]) (amavisd-new, port 10024) with ESMTP id jjYUf2iM0Jc9; Wed, 11 Nov 2015 10:37:35 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 36D435BC02A; Wed, 11 Nov 2015 10:37:38 +0200 (EET)
Date: Wed, 11 Nov 2015 10:37:33 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Justin Richer <jricher@mit.edu>
Message-ID: <20151111083733.GA32165@LK-Perkele-V2.elisa-laajakaista.fi>
References: <255B9BB34FB7D647A506DC292726F6E13BB1B6894C@WSMSG3153V.srv.dir.telstra.com> <77F4F506-1924-45A7-94CB-3C530968244B@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <77F4F506-1924-45A7-94CB-3C530968244B@mit.edu>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/Vc6r0pudcpJWg88jcNVOriW32xk>
Cc: James Manger <James.H.Manger@team.telstra.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] CFRG ECC in JOSE - thumbprint
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: Wed, 11 Nov 2015 08:37:56 -0000

On Tue, Nov 10, 2015 at 08:22:53PM -0500, Justin Richer wrote:
> I would lean toward using a new “kty” value for these as the syntax
> is different from existing ones. This will help parsers and existing
> implementations add this in without adding special processing rules:
> code is already set up to branch on “kty” so let’s keep that
> behavior. Note you can still reuse parts of the key definition
> (like “d” is found in both RSA and EC keypairs) without having to
> overload a new syntax since the kty defines a new namespace,
> effectively. I suggest a value of “ED” since they’re all “edwards”
> curves from my quick read.

1) Actually, I think "okp" (Octet Key Pair) or something like that
might be more descriptive, since these are keypairs with no structure
outside the box ("oct" or whatever won't do, since that's symmetric,
not asymmetric). This also holds for X25519 and X448.

2) IIRC, the definition of "EC" talks about all defined curves having
"y", but not necressarily all curves having "y". Might be bad idea
implementation-wise to use that option however (I did encounter
comments about this pre-draft that indicated that options realistically
available are less than what JWK provodes).

3) I think it is a bad idea not to vary key fingerprint on algorithm.
However, that ship has already sailed.


-Ilari