Re: [Cfrg] EC signature: next steps
Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 31 August 2015 17:05 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BC01A9034 for <cfrg@ietfa.amsl.com>; Mon, 31 Aug 2015 10:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 QUewPzJkTX-P for <cfrg@ietfa.amsl.com>; Mon, 31 Aug 2015 10:05:16 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6138C1A9030 for <cfrg@irtf.org>; Mon, 31 Aug 2015 10:05:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BDBF9BE5D; Mon, 31 Aug 2015 18:05:13 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vn8kQRLAGypy; Mon, 31 Aug 2015 18:05:12 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.29.89]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 108E8BE58; Mon, 31 Aug 2015 18:05:12 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1441040712; bh=M5XKpxwUuk7vyeltTphh/X60kzKcf3F1TahidTFqBdE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=sp0mRFr8q+GsFEk6dPw0rlLE4B2gQCcT7WxMg7jXs5K5qs+QvH7c0p1ULRXZcYCe4 PCsnOKSq1QZE07T6/7YS5H01Kj2xRTlO6WSNIPPPIo0+l0Rrp68Cu/CjOaIYqjKVnj Hro/Vzc8LttBxJlZoAmJlv3XR6rzBTUK0Q7rFWyE=
To: Alexey Melnikov <alexey.melnikov@isode.com>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <55DD906F.3050607@isode.com> <D2035132.531EE%kenny.paterson@rhul.ac.uk> <55DDA21D.9060302@isode.com> <55DF3E3C.7020206@isode.com> <55E42414.3020805@isode.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
X-Enigmail-Draft-Status: N1110
Message-ID: <55E48947.5070102@cs.tcd.ie>
Date: Mon, 31 Aug 2015 18:05:11 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55E42414.3020805@isode.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/uQPl0ectxX8qMULw1FuuJ1i1mmY>
Subject: Re: [Cfrg] EC signature: next steps
X-BeenThere: cfrg@mail.ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.mail.ietf.org>
List-Unsubscribe: <https://mail.ietf.org/mailman/options/cfrg>, <mailto:cfrg-request@mail.ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@mail.ietf.org>
List-Help: <mailto:cfrg-request@mail.ietf.org?subject=help>
List-Subscribe: <https://mail.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@mail.ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2015 17:05:19 -0000
Hi Alexey, On 31/08/15 10:53, Alexey Melnikov wrote: > Dear CFRG participants, > > Many thanks to Ilari for posting this updated summary of where things > currently stand. Kenny and I would now like to run a short discussion > focusing on this summary, with our intention being to flush out any last > issues or additional points of comparison between the different schemes > that everyone should be aware of. > > Once everyone has kicked the tires, so to speak, we plan to move to a > poll to decide which scheme CFRG should focus on writing up and formally > recommending. We, as chairs, are hoping these steps will get us to the > finishing line. > > So: > > - are there important characteristics or points of comparison that > Ilari's summary does not cover? IPR. There have been a few modifications to the schemes compared to when those were initially proposed during the process. One of the things that IETF working groups (well, document shepherds) do these days is to get authors of documents to re-confirm that yes, they have in fact ensured that all required IPR declarations have been made. That does catch some errors and omissions that would otherwise cause issues later in the process. While we don't yet have a draft here, I think it would be a valuable input if each of the authors commented in the next week as to whether or not they are personally aware of any IPR that affects their proposal. (Of course, if they know of IPR that affects someone else's proposal then our IPR process also does ask that they tell us about that too.) And again, as with the document shepherd case, it'd be fine if they just sent mails to the chairs who then summarised to the list before you start that poll, e.g. saying who had (or had not) sent you such a mail and what they said. (On list would be fine but might get fractious, hence my suggestion that the chairs summarise.) And just to be very clear, the information that I would find useful in that aspect of the evaluation is whether or not some IPR declaration will be needed should CFRG select the proposal concerned. The actual declaration would of course follow in due course but knowing now that the proponents do not expect to have to make such a declaration would be good input for me. So simply saying "this is the same as <<that>>" is not a useful answer for me for any value of <<that>>. Hopefully, the answer is that nobody has an issue saying that they will not need to make an IPR declaration for their scheme, but confirming that, or folks inability to state that, would be useful as there is history in this space and that kind of problem could also ensure that CFRG is delayed to the point where the chosen scheme is overtaken by events. Thanks, S. > > - are there errors of fact or omission that need to be corrected? > > - anything else? > > > We'll let this discussion run for exactly one week, but we might extend > the time if the discussion is still going strong and new arguments or > points of comparison are brought up. After that, if no major new > information is brought up, we will start the Quaker poll for selecting a > single CFRG-recommended signature scheme. > > > Best Regards, > Kenny and Alexey > > _______________________________________________ > Cfrg mailing list > Cfrg@mail.ietf.org > https://mail.ietf.org/mailman/listinfo/cfrg >
- [Cfrg] EC signature: next steps Alexey Melnikov
- Re: [Cfrg] EC signature: next steps Simon Josefsson
- Re: [Cfrg] EC signature: next steps Watson Ladd
- [Cfrg] EC signature: next steps Dan Brown
- Re: [Cfrg] EC signature: next steps Ilari Liusvaara
- Re: [Cfrg] EC signature: next steps Stephen Farrell
- Re: [Cfrg] EC signature: next steps Dan Brown
- Re: [Cfrg] EC signature: next steps Simon Josefsson
- Re: [Cfrg] EC signature: next steps Ilari Liusvaara
- [Cfrg] Side inputs to signature systems D. J. Bernstein
- Re: [Cfrg] Side inputs to signature systems Natanael
- Re: [Cfrg] EC signature: next steps Simon Josefsson
- Re: [Cfrg] Side inputs to signature systems Michael Hamburg
- Re: [Cfrg] EC signature: next steps Rene Struik
- Re: [Cfrg] EC signature: next steps David Jacobson
- Re: [Cfrg] EC signature: next steps Mike Hamburg
- Re: [Cfrg] EC signature: next steps William Whyte
- Re: [Cfrg] EC signature: next steps Stephen Farrell
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] EC signature: next steps Ilari Liusvaara
- Re: [Cfrg] EC signature: next steps Stephen Farrell
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] key as message prefix => multi-key sec… Dan Brown
- [Cfrg] key as message prefix => multi-key security D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… Paterson, Kenny
- Re: [Cfrg] key as message prefix => multi-key sec… Sven Schäge
- Re: [Cfrg] key as message prefix => multi-key sec… Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] key as message prefix => multi-key sec… William Whyte
- Re: [Cfrg] key as message prefix => multi-key sec… Bill Cox
- Re: [Cfrg] key as message prefix => multi-key sec… Andrey Jivsov
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… Eike Kiltz
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… Simon Josefsson