Re: [jose] draft-ietf-jose-cfrg-curves
"Jim Schaad" <ietf@augustcellars.com> Wed, 02 March 2016 22:22 UTC
Return-Path: <ietf@augustcellars.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 A6DC51B32F2 for <jose@ietfa.amsl.com>; Wed, 2 Mar 2016 14:22:54 -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 WkyjnsGZ0hIy for <jose@ietfa.amsl.com>; Wed, 2 Mar 2016 14:22:52 -0800 (PST)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822561B32ED for <jose@ietf.org>; Wed, 2 Mar 2016 14:22:45 -0800 (PST)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id AD7732CA07; Wed, 2 Mar 2016 14:22:44 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: ilariliusvaara@welho.com
References: <036c01d174c9$85313c60$8f93b520$@augustcellars.com> <20160302220217.GA11954@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20160302220217.GA11954@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Wed, 02 Mar 2016 14:22:43 -0800
Message-ID: <038201d174d2$0b10f570$2132e050$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHP8FilIkyb2BLc6wB7dIJJdjUheQJ3NuyGnzYJWhA=
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/P1lXKZzYTdX5pjRgzBM1b4-Qzjc>
Cc: draft-ietf-jose-cfrg-curves@tools.ietf.org, jose@ietf.org
Subject: Re: [jose] draft-ietf-jose-cfrg-curves
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, 02 Mar 2016 22:22:54 -0000
> -----Original Message----- > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > Sent: Wednesday, March 02, 2016 2:02 PM > To: Jim Schaad <ietf@augustcellars.com> > Cc: draft-ietf-jose-cfrg-curves@tools.ietf.org; jose@ietf.org > Subject: Re: [jose] draft-ietf-jose-cfrg-curves > > On Wed, Mar 02, 2016 at 01:21:43PM -0800, Jim Schaad wrote: > > Given that there has been a last call on the eddsa draft in CFRG, I > > would like to get an update to this document. To this end I have > > re-read the document to provide feedback. I would encourage others to do > the same. > > Thanks. > > > Section 1 - > > s/in inter-operable manner/in an interoperable manner/ > > That's what I get from relying on spellcheckers too much... :-) > > > * As has been discussed on the mailing list by the two of us, I would > > support narrowing down to having only the one from of the two > > signature algorithms presented. I think that a brief discussion of the reasons > behind > > this would be appropriate to occur in this section. For the 90% case there > > is no problem for JOSE not to have an incremental update digest > > version of the signature algorithm. I will note that currently there > > is no streaming version of digesting for the W3C web crypto API so it > > would not be used for any code using that API today. Most content > > that JOSE signs today is small so again this is not a problem. While > > there is a new document which will potentially be used for large > > content, we do not yet know that not having a streaming digest API is > > a problem. If it because one then this decision can be revisited. > > However the potential security issues that have been brought up about > > confusion between the two algorithms is a problem that can be avoided. > > Dropped Ed25519ph and Ed448ph from editor's copy. > > > Section 2 - > > > > * After long thought and the brief discussion on the list. I am now > > of the opinion that eliminating "crv" and using "alg" in its place > > while a good idea for the signature algorithms, is problematic for the > > key agreement algorithm set. I would therefore encourage leaving > > things as it currently stands so we do not need to define a large > > number of new "crv" values to deal with the cross product of ECDH algorithms > and OKP curves. > > > > * Given that one can define the set of required parameters, it would > > not matter if alg was required here and not for some other key type. > > If you want to mandate it be present, be my guest. > > Well, at least with Ed25519 and Ed448 verification, if you get it wrong, the > verification will blow up due to wrong keylength. > > > Section 3.1.1 > > > > * I would agree that it makes sense to have a single algorithm values > > in many respects. > > > > * If one reduces the number of algorithms, does it make sense to go > > with two different ones - one with no pre-hash and one with pre-hash defined > as ... > > Well, the idea would be: sign with key using method appropriate for the key. > > Also, even if it would be possible to make a prehashed variant without running > into the issues Ed25519ph itself has (with the prehash mixups), is that a good > idea? > > (Those ways are bit poor match to JOSE architecture tho). Given that you have eliminated the *ph algorithms, the idea of two signature algorithms does not really make a great deal of sense. Have a single EdwardsSignature algorithm still does. Jim > > > Section 3.2 > > > > * The algorithm "Enc" is incorrect. It should be "ECDH-ES" > > Oops, probably misread some example. Fixed. > > > Section 4. > > > > * I was surprised to see the comment about an RNG being needed for > > batch validation. I looked for similar text in the CRFG document and > > was not able to find it. > > I think some considerations on this were added very recently (like last day or > two). > > > -Ilari
- [jose] draft-ietf-jose-cfrg-curves Jim Schaad
- Re: [jose] draft-ietf-jose-cfrg-curves Ilari Liusvaara
- Re: [jose] draft-ietf-jose-cfrg-curves Jim Schaad
- Re: [jose] draft-ietf-jose-cfrg-curves Ilari Liusvaara