Re: [Cfrg] Patents and the new elliptic curves

Alyssa Rowan <akr@akr.io> Wed, 17 September 2014 23:04 UTC

Return-Path: <akr@akr.io>
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 089511A03CA for <cfrg@ietfa.amsl.com>; Wed, 17 Sep 2014 16:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.502
X-Spam-Level:
X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 oEM_JOg0v5F2 for <cfrg@ietfa.amsl.com>; Wed, 17 Sep 2014 16:04:14 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204C31A02E1 for <cfrg@irtf.org>; Wed, 17 Sep 2014 16:04:14 -0700 (PDT)
Message-ID: <541A136D.2080509@akr.io>
Date: Thu, 18 Sep 2014 00:04:13 +0100
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: Benjamin Black <b@b3k.us>
References: <2145381D-E1C4-4CFC-A26F-879D775E6558@shiftleft.org> <541932C3.10604@akr.io> <CA+Vbu7zuN2+U-A+q3gMs61rHNYH3K=eJNeK9daUP309mqpp6AA@mail.gmail.com>
In-Reply-To: <CA+Vbu7zuN2+U-A+q3gMs61rHNYH3K=eJNeK9daUP309mqpp6AA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/pgAe610qOxw3-QrY1ixmZEK_HY4
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Patents and the new elliptic curves
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Sep 2014 23:04:16 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 17/09/2014 09:41, Benjamin Black wrote:

> [a bunch of stuff]

Wow. Look. I am quite plainly not in a position to demand, or bully,
anything from anyone. If you somehow read my questions, suggestions
and requests in that way in our offlist discussion, despite the CCs,
then I think we have perhaps simply reached a profound misunderstanding.

I simply want the situation regarding all proposals to be as clear as
it can be: and at present, X25519 and Ed25519 seem, I think, much
clearer than NUMS. (I am slightly less clear about Goldilocks and
E-521, but I've looked into them less.) I think we all want
transparency on this, given the general area of the IP1 and IP2
requirements.

I would have thought anyone implementing their proposal in their
reference implementation, treading on a fairly-specific comb patent
they didn't know about - owned by the same company, but somehow missed
in a careful pre-release legal review despite the open-source licence
containing a limited patent grant - would understand why everyone
wants as much clarity as possible in this area. Nobody wants anything
up _anyone's_ sleeves, really. Our interests all align there.

I have indeed previously misinterpreted the scope of the BCP - which
is not quite as wide as I had thought and indeed does not cover
reference implementations as submissions itself - although it makes it
terribly hard to discuss performance characteristics, which I think
will an important factor in upstream adoption, in real terms without
at least considering reference implementations. I've tried to correct
my misunderstanding there. I still think it would benefit everyone if
all participants could clear the minefield as much as possible, and I
think we're all on the same page about that generally.

In particular, I do suggest that it'd benefit all proposals if
reference implementations were available for as wide use as possible,
as clearly as possible. That seems strongly in the spirit of IP1 and
IP2, and also in the spirit of recommendations actually getting _used_
upstream, which you also want. That's why I suggested that you could,
if you wished, take an approach that wouldn't be incompatible with
GPLv2 (cf: Linux) & BSD (cf: BSDs) licences as I believe Apache 2.0
is, but could actually (as you say) eliminate IPR concerns; Opus might
be a good case study here?

In any case, I very much look forward to hearing what, if anything,
you do propose, and the result of any legal review if you care to let
us know. Thanks.

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUGhNtAAoJEOyEjtkWi2t6y3kQAIqiB+pn+xXuakE4b58evvgD
9ZnqEJzJUVPDzsfj74YdBHHFQPd2UuovdqEFz05wYVezCnvI4HTrzvu9cO5orwDw
fINsi5Kgh2TzEjaGfHqRHj1nzJYBm4eXlSuhBGz5hgye0Gncy2K9W7OBmBoeSocA
1Q/t8S1BqO+6InykfQmAJ6pwJCHD20lNSuUyFrkMaC8eX8g1Z8PO7Q6dJu7XAQbV
d7GtK64DRQVMM8/m4pw7+60Vj3ICxpfyjmmVvVbC4S/9tFUrBmYXzm8LfWiqFPzf
zBr9qa0TQB+egBqgK3pXaJWBlrFN5U33Wf/l/MrQJ5qqbLte5pulcxSB/65JMGeq
JbcTuvEkwPVZhqu++h7aFv09veJipz/uVytya0wG0xD25+u8t9tw08CJf3qTUACq
dJNsTESMdFCe/ZFji3k3z/P5dR3o2DgELbJgwI3wNtFU/Z5E0MtHTbQLCxt/ACsZ
eU7wAQ2ElczKchWdJxy9g8DAGXUOzJ2+H7tXJplqFfVpIqPXqkC9UjTJtWy1vV2Y
XV121DBfsEj95YDoeZMSa9jMyqet32ph4T01WlAs4CnCwtQtvgrx6p7U5akqeg3y
v1Xc/se+HMn3phVf/XKshGsHtSiFPW1F65r32BHNg+whD0u2wgkFvZSeQe8FXy2N
QSCq9NPgVSSQNr1Nkiy+
=N8uD
-----END PGP SIGNATURE-----