Re: [Cfrg] New Version Notification for draft-whyte-select-pkc-qsh-00.txt

Simon Josefsson <simon@josefsson.org> Tue, 22 September 2015 14:25 UTC

Return-Path: <simon@josefsson.org>
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 F127E1A890E for <cfrg@ietfa.amsl.com>; Tue, 22 Sep 2015 07:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
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 mEsrGFpKv5tA for <cfrg@ietfa.amsl.com>; Tue, 22 Sep 2015 07:25:17 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2474C1A8906 for <cfrg@irtf.org>; Tue, 22 Sep 2015 07:25:16 -0700 (PDT)
Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t8MEOq8n011634 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 22 Sep 2015 16:24:53 +0200
Date: Tue, 22 Sep 2015 16:24:50 +0200
From: Simon Josefsson <simon@josefsson.org>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Message-ID: <20150922162450.52515bbc@latte.josefsson.org>
In-Reply-To: <20150922133900.17789008.7169.24365@ll.mit.edu>
References: <D225E3A1.1F4FD%uri@ll.mit.edu> <87k2rj4gjw.fsf@latte.josefsson.org> <9A043F3CF02CD34C8E74AC1594475C73F4B1953C@uxcn10-5.UoA.auckland.ac.nz> <8737y651nh.fsf@latte.josefsson.org> <20150922133900.17789008.7169.24365@ll.mit.edu>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; boundary="Sig_/Tf6iLdrfScCmFN6VWM4N4it"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/_oYCdppGPBCH3t8ulFO-Qwf6BTk>
Cc: CFRG <cfrg@irtf.org>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
Subject: Re: [Cfrg] New Version Notification for draft-whyte-select-pkc-qsh-00.txt
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: Tue, 22 Sep 2015 14:25:20 -0000

> Simon, I'm not sure I understand. 
> 
> For the sake of the argument, assume company A allows free use of
> their patented algorithm B in TLS. ‎OpenSSL project notifies A that
> it's about to include B in the codebase. In which case A can answer
> "Go ahead", "No way", or "Pay us". In the two latter cases, the
> algorithm simply won't end up included. Ideally, this exchange
> happens before the TLS WG standardizes/accepts B. 

This raises several questions:

1) What do you mean by "free use"?  If it is really free use, there is
no need to ask for permission, and there is no way for the company to
say "no way" or "pay us".

2) If the "in TLS" part is a crucial part of there patent licensing, it
may matter how the integration works.  Is the algorithm usable without
TLS or not?

3) In practice having this dialogue is difficult.  NDAs is usually a
non-starter for a FOSS project.  For example, I tried having a
discussion with RedPhone for the TLS Authorization extension that I
implemented in GnuTLS and that fell apart.  Often the company benefits
from having projects being in the dark about whether they are allowed
to use the technology or not (FUD tactic).

/Simon

> 
> Sent from my BlackBerry 10 smartphone on the
> Verizon Wireless 4G LTE network. Original Message  
> From: Simon Josefsson
> Sent: Tuesday, September 22, 2015 03:55
> To: Peter Gutmann
> Cc: Blumenthal, Uri - 0553 - MITLL; CFRG
> Subject: Re: New Version Notification for
> draft-whyte-select-pkc-qsh-00.txt
> 
> Peter Gutmann <pgut001@cs.auckland.ac.nz> writes:
> 
> > Simon Josefsson <simon@josefsson.org> writes:
> >
> >>That is not consistent with my view or experience. If you publish a
> >>library that implements a patented algorithm, and your library is
> >>popular enough to attract attention from the patent holder, you
> >>will have a hard time.
> >
> > Only if you're using someone else's patented algorithm
> > inappropriately. My code had IDEA (for PGP 2.x support) in it, I
> > included Ascom Tech's patent statement in the docs as they
> > requested giving the T&C under which it could be used, and sent
> > them a courtesy note about it. I got a reply from them that said
> > something like "thanks for the note, and all the best with your
> > work". So provided you play by the rules (whether you agree with
> > them or not), things should be OK.
> 
> They realized they couldn't charge you, and that having IDEA in your
> product would allow them to charge others. Others ended up paying for
> IDEA, or refused to work with it (like libgcrypt). This is what I
> refer to by "having a hard time".
> 
> Going back to the original topic: I don't think what you are
> describing is a workable approach for a general patent rule when
> considering which algorithms to consider here.
> 
> /Simon
>