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

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 21 Sep 2015 21:03:06 +0000

On 9/21/15, 15:06 , "Simon Josefsson" <[email-masked]> wrote:

>"Blumenthal, Uri - 0553 - MITLL" <[email-masked]> writes:
>>In my 2+ decades of IETF/IRTF experience, the choice has been to stay
>>away
>> from patented non-free algorithms, period. Thus an acceptable candidate
>> algorithm must be FPARF (Free or Patented and Royalty-Free for use in
>>IETF
>> protocols :).
>
>I believe we have seen evidence that even the qualifier "for use in IETF
>protocols" is too limiting.

Maybe. 

I’d say that “free for use in IETF protocols” is the absolute minimum
required for acceptance (or even consideration). But still an acceptable
minimum - which is a whole lot better than “Reasonable and
Non-Discriminatory" licensing fee.

>Many crypto libraries cannot know for what
>purpose their APIs will be used for, so limiting the ability to use an
>algorithm for "an IETF protocol" is in practice a non-starter for
>deployment.

There’s a big difference between a library and a protocol. Not to mention
that IETF traditionally does not deal with either API or libraries.

A library may include whatever algorithm the authors/maintainers want to -
the legal issues usually fall on the lap of the user, unless the library
is a commercial product, in which case it’s a whole different ballgame. So
including a ton of algorithms in a library regardless of their patent
status is probably fine - nobody forces a commercial user of that library
to invoke what's “forbidden” instead of what’s “permitted”.  Besides, I
seldom see a library deployed by itself (especially where it could matter
- where the “license police” would come to look for your “license") -
usually it’s included as a part of a product, an application or such. In
which case there (again, usually) is a way to tell the whole thing “use
SHA256, and don’t use MD4 even if it happens to be included in the
library”. If not - I suggest deploying a product that is better designed
and implemented. :-)

A protocol is something that IETF defines, and requires those who claim
conformance to actually implement the algorithms included in that
definition. Specifying an algorithm here subjects both developer (who may
want to sell the conformant product) and user (who unsurprisingly may want
to use this conformant product) to potential legal licensing issues. Which
I personally find undesirable and inexcusable.

So, a library is something outside of IETF scope (or interest), and can
contain anything. A protocol is something “blessed” by IETF, and it better
not contain algorithms that require licensing fees in any shape or form
(yes I’m aware of exceptions, and want to see their number drop, not
increase).

>>P.S. I concur with Stephen: "anyone spending time here on developing or
>> reviewing proposals that involve encumbered crypto algorithms is simply
>> wasting that time."
>
>+1

:-)

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 21 Sep 2015 23:18:43 +0200

"Blumenthal, Uri - 0553 - MITLL" <[email-masked]> writes:

> the legal issues usually fall on the lap of the user,

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.

> unless the library is a commercial product, in which case it’s a whole
> different ballgame.

In what sense?  The majority of libraries we are talking about (OpenSSL,
libgcrypt, Apple's crypto libraries, Microsoft's crypto libraries, etc)
are sold commercially.  I cannot come up with any crypto library that
would be relevant to the Internet that is not sold commercially.

> (yes I’m aware of exceptions, and want to see their number drop, not

Lucky we are in the IRTF here and not in the IETF then. :-)

/Simon

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 21 Sep 2015 21:35:19 +0000

>popular enough to attract attention from the patent holder, you will

You have a point. 

Though with an Open Source library the patent holder may have a harder
time proving damages to cause you trouble.

Usually the most they (the patent holders) can do is force you to remove
their patented stuff from your library. And in case of such vindictive
patent holders - I’d say “good riddance” :-)

>In what sense?  

In the sense that a patent holder can claim royalties/fees/damages from
the *seller* (and/or from known “deep-pockets” users) of a commercial
product that implements patented algorithm(s) without licensing them from
the patent holder. It is harder (but not impossible) with a freeware.
Remember the original PGP? And efforts by RSADSI Inc. to affect it?

>The majority of libraries we are talking about (OpenSSL,
>are sold commercially.

So I suspect that Apple and Microsoft paid licensing fees to all the
patent holders of all the relevant patented algorithms (ECC comes to mind)
that their crypto libraries contain.

>I cannot come up with any crypto library that
           ^^^^^^^^^^^^^^^^^^^^^^^^ not sure here
Last I checked, OpenSSL was freely available. Same with libgcrypt.

Not sure about the “relevant to Internet” part, but: Crypto++, Botan,
PyCrypto.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Sep 2015 21:39:36 +0000

> time proving damages to cause you trouble.

Taking them to court is usually more than enough to cause the project trouble.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 21 Sep 2015 23:47:39 +0200

> Not sure about the “relevant to Internet” part, but: Crypto++, Botan,

They are all sold commercially.  Freely available doesn't mean you can't
sell them.  In fact, a free software license requires users to have the
ability to sell the software.

/Simon

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 21 Sep 2015 21:49:02 +0000

>Taking them to court is usually more than enough to cause the project

Yes, you’re right.

I don’t know what to do with cases when a patent holder is allowing
royalty-free use of his algorithms within IETF protocols, but does not
want to completely release the patent to public domain. If you say “don’t
consider it unless it is royalty-free with no restrictions, period” - I
can live with that.

---

From: James Cloos <[email-masked]>
Date: Mon, 21 Sep 2015 19:59:32 -0400

>>>>> "SJ" == Simon Josefsson <[email-masked]> writes:

SJ> They are all sold commercially.  Freely available doesn't mean you
SJ> can't sell them.  In fact, a free software license requires users
SJ> to have the ability to sell the software.

And then there is the issue that if one were to take some GPLed code,
add a patented algorithm which requires royalties, one then could not
not distribute the resulting code w/o violating the licence of the
upstream code.

Any curves or algorithms cfrg works on should be fully unburdened.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 22 Sep 2015 07:01:15 +0000

Simon Josefsson <[email-masked]> 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.

Peter.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 22 Sep 2015 09:55:14 +0200

> provided you play by the rules (whether you agree with them or not), things

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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 22 Sep 2015 13:38:51 +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. 

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

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 22 Sep 2015 16:24:50 +0200

> 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
> >>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.
> 
> 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
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 22 Sep 2015 15:37:03 +0000

My $0.02 worth of answer:

1. By "free use" I meant "free use within the TLS framework and implementation" (or within IETF protocols framework), so a generic crypto library maintainer could feel the need to make sure that patent holder's permission covers the *library itself* as well,  which - as you pointed out - cannot ‎know who uses its API and for what purposes. I agree that for something that is (mainly) used in the TLS protocol itself (rather than being a general-purpose crypto library usable for TLS among other things, like e.g. Botan) there shouldn't need to ask permission.

2. If the algorithm is not usable outside of (e.g.) TLS - then this whole discussion/issue is moot: if the patent holder said "free use in TLS" and it isn't suitable for anything else - just implement it. If the algorithm is usable elsewhere, but the permission covers only (e.g.) TLS - then a generic library maintainer would ask the patent holder for permission to include the algorithm. And if permission is not granted - it should be an argument for the TLS WG to avoid that algorithm.

3. NDA must not be involved. The patent holder either says "Yes our permission to use this algorithm in IETF standards such as TLS extends to your library that implements it", or not (and anything other than straight "yes" counts as "no") - in which case the algorithm is a no-go (of course). 
(I've seen enough FUD in related issues, especially with some algorithms and some patent holders. :)

It all isn't great, I know.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Simon Josefsson‎
Sent: Tuesday, September 22, 2015 10:25
To: Blumenthal, Uri - 0553 - MITLL
Cc: Peter Gutmann; CFRG
Subject: Re: New Version Notification for draft-whyte-select-pkc-qsh-00.txt
‎

‎

/Simon