Richard M Stallman | 1 Jul 01:03 2008
Picon
Picon

Re: Document Action: 'TLS Elliptic Curve Cipher Suites with

    Discussing IPR issues burns a whole lot of resources in a useless fashion.

Since "IPR" refers to a congeries of different laws, any general
statement about "IPR issues" is almost always an overgeneralization.
Your statement is one.

Copyright issues and trademark issues generally do NOT cause serious
problems for a proposed technique, because it is easy enough to work
around them.  To discuss them here at length would probably be
superfluous.

By contrast, patent problems are often fatal, and there is no remedy
except to wait as much as 20 years.  Thus, discussing whether a
proposed technique is patented is absolutely crucial.

Lumping together things which are so different in their effects is
encouraging confusion.  Thus, using the term "IPR" does only harm.
Avoiding it is easy, so let's avoid it.  When referring to patent
issues, let's call them "patent issues".
Mark Tillinghast | 1 Jul 08:21 2008
Picon
Picon

Re: Document Action: 'TLS Elliptic Curve Cipher Suites with

Hello,
I did want to encourage people to have a look at Matthew Campagna's post.
I am not sure that people hav seen this. And it is authoritative-- I 
instigated this though my contacts at certicom to clarify their position on 
this issue in the hope that we could marshall our way past these issues..
Please have a look as it should alay doubts or misgivings; surely those 
related to Certicom's "patent issues" involvement in ECC.
Thank You,
Mark
----- Original Message ----- 
From: "Richard M Stallman" <rms <at> gnu.org>
To: <martin.rex <at> sap.com>
Cc: <tls <at> ietf.org>; <iesg <at> ietf.org>
Sent: Monday, June 30, 2008 4:03 PM
Subject: Re: [TLS] Document Action: 'TLS Elliptic Curve Cipher Suites with

>    Discussing IPR issues burns a whole lot of resources in a useless 
> fashion.
>
> Since "IPR" refers to a congeries of different laws, any general
> statement about "IPR issues" is almost always an overgeneralization.
> Your statement is one.
>
> Copyright issues and trademark issues generally do NOT cause serious
> problems for a proposed technique, because it is easy enough to work
> around them.  To discuss them here at length would probably be
> superfluous.
>
> By contrast, patent problems are often fatal, and there is no remedy
> except to wait as much as 20 years.  Thus, discussing whether a
(Continue reading)

Yoav Nir | 1 Jul 08:10 2008
Picon

Re: Document Action: 'TLS Elliptic Curve Cipher Suites with

OK, but Martin is correct about patent issues as well. We can discuss  
patent issue on and on, but we can't really get to any solid  
conclusions.

None of us on the TLS mailing list is a lawyer, definitely not a  
patent lawyer, and even if we were, the discussion about whether or  
not a patent applies will usually never terminate. The only way to  
really know is to implement, wait for the lawsuit, and see who wins.  
Unfortunately, most implementers, especially commercial ones are not  
willing to take this route.

Looking for unencumbered alternatives is even more tricky.  We know  
(or think) that TLS-SRP is encumbered. Suppose we took these guys'  
proposal to create an unencumbered alternative:
http://www.lightbluetouchpaper.org/2008/05/29/j-pake/

They claim that JPAKE is unencumbered, so TLS-JPAKE should be  
unencumbered, no?  Well, we don't really know - it's hard to prove a  
negative. If we go ahead and specify and implement TLS-JPAKE, somebody  
might come out of the woodwork and claim we are infringing.  All the  
discussion on the TLS or IESG mailing lists is not going to change that.

On Jul 1, 2008, at 2:03 AM, Richard M Stallman wrote:

>    Discussing IPR issues burns a whole lot of resources in a useless  
> fashion.
>
> Since "IPR" refers to a congeries of different laws, any general
> statement about "IPR issues" is almost always an overgeneralization.
> Your statement is one.
(Continue reading)

Pasi.Eronen | 1 Jul 10:09 2008
Picon

Re: Document Action: 'TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode' to Informational RFC

Dean,

The ECC algorithms are specified in RFC 4492, not in this document. 
In other words, you cannot implement this document without reading 
and implementing large parts of RFC 4492.

When a "base document" of some protocol or feature has IPR
disclosures, it hasn't been common to submit IPR disclosures for
"extension documents" or features (which also require implementing the
base protocol/feature), unless the extension itself has some new IPRs.

For example, the SIP base protocol (RFC 3261) has an IPR disclosure, 
but when doing an IPR disclosure search for some SIP extension (say,
draft-vanelburg-sipping-served-user) on the IETF page, you get only
IPR disclosures specific to that extension. Perhaps adding a
"recursive IPR disclosure search" feature would be useful, though.

Given this, I don't find the situation at all similar to TLS-Authz;
the necessary IPR disclosures have been filed. Certicom has also
promised to update the licensing statement (which is not required
by BCP79) to make it clearer that it applies to this document as 
well. 

Non-patended (non-ECC-based) alternatives were discussed in the 
WG, and a document specifying them (TLS cipher suites that use 
non-ECC key exchange with GCM mode), draft-ietf-tls-rsa-aes-gcm,  
was approved on the same day as this document.

Best regards,
Pasi 
(Continue reading)

Pasi.Eronen | 1 Jul 11:01 2008
Picon

Re: Document Action: 'TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode' to Informational RFC

I already replied about most of the subtopics, but addressing
the question of WG consensus specially:

Eric Rescorla wrote:
> Dean Anderson wrote:
> > 3. No consensus on WG, despite relationship to prior and future
> > standards-track work on TLS.
> 
> Again, I'll refer this to Pasi, who ran this WGLC as chair.

The document went through WGLC, and several people provided
comments (some of which resulted in small changes). There 
was rough consensus send it to IETF last call with intended
status of Informational.

Best regards,
Pasi
Richard M Stallman | 1 Jul 22:37 2008
Picon
Picon

Re: Document Action: 'TLS Elliptic Curve Cipher Suites with

    They claim that JPAKE is unencumbered, so TLS-JPAKE should be  
    unencumbered, no?  Well, we don't really know - it's hard to prove a  
    negative. If we go ahead and specify and implement TLS-JPAKE, somebody  
    might come out of the woodwork and claim we are infringing.  All the  
    discussion on the TLS or IESG mailing lists is not going to change that.

All that is true, but doesn't the IETF have ways to press the big
companies to say whether they have any patents over a proposed
standard?
Paul Hoffman | 1 Jul 23:01 2008

Re: Document Action: 'TLS Elliptic Curve Cipher Suites with

At 4:37 PM -0400 7/1/08, Richard M Stallman wrote:
>All that is true, but doesn't the IETF have ways to press the big
>companies to say whether they have any patents over a proposed
>standard?

No.

--Paul Hoffman, Director
--VPN Consortium
Simon Josefsson | 2 Jul 00:15 2008

Re: Document Action: 'TLS Elliptic Curve Cipher Suites with

Paul Hoffman <paul.hoffman <at> vpnc.org> writes:

> At 4:37 PM -0400 7/1/08, Richard M Stallman wrote:
>>All that is true, but doesn't the IETF have ways to press the big
>>companies to say whether they have any patents over a proposed
>>standard?
>
> No.

That is a rather terse answer.

The IETF has RFC 3979, in particular section 6.1, which says that IETF
participants must file a disclosure when he knows about his own patents
in IETF contributions, and is encouraged to file a disclosure for
patents owned by others.  That count as a "yes" answer to this question
for me.

To clarify, the IETF has RFC 3979 as the instrument to pressure big
companies to file these notifications, through the individuals who
participate in the IETF.

Could you elaborate on why you believe "no" is the correct answer?

/Simon
Dan Harkins | 2 Jul 00:33 2008

Re: Document Action: 'TLS Elliptic Curve Cipher Suites with


  Hi Simon,

  "no" is the correct answer for J-PAKE because the the creators of
the protocol said, "Since this protocol is the result of an academic
research project, we didn’t — and have no intention to — patent it."
But that says nothing about anyone else's claims.

  So if, hypothetically, one of the creators of J-PAKE wrote an I-D
specifying its use in TLS then he would not have to file anything on
that contribution since he knows he did not patent it. But "Patent
Trolls R Us (tm)" could believe it held a patent on this technique and
I am not aware of anything the IETF could do to compel them to disclose
their patent since no employee of "Patent Trolls R Us (tm)" took part
in the authorship of the I-D.

  So, I think "no" is the correct answer.

  Dan.

On Tue, July 1, 2008 3:15 pm, Simon Josefsson wrote:
> Paul Hoffman <paul.hoffman <at> vpnc.org> writes:
>
>> At 4:37 PM -0400 7/1/08, Richard M Stallman wrote:
>>>All that is true, but doesn't the IETF have ways to press the big
>>>companies to say whether they have any patents over a proposed
>>>standard?
>>
>> No.
>
(Continue reading)

Paul Hoffman | 2 Jul 00:56 2008

Re: Document Action: 'TLS Elliptic Curve Cipher Suites with

At 12:15 AM +0200 7/2/08, Simon Josefsson wrote:
>Paul Hoffman <paul.hoffman <at> vpnc.org> writes:
>
>>  At 4:37 PM -0400 7/1/08, Richard M Stallman wrote:
>>>All that is true, but doesn't the IETF have ways to press the big
>>>companies to say whether they have any patents over a proposed
>>>standard?
>>
>>  No.
>
>That is a rather terse answer.

Good catch.

>The IETF has RFC 3979, in particular section 6.1, which says that IETF
>participants must file a disclosure when he knows about his own patents
>in IETF contributions, and is encouraged to file a disclosure for
>patents owned by others.  That count as a "yes" answer to this question
>for me.
>
>To clarify, the IETF has RFC 3979 as the instrument to pressure big
>companies to file these notifications, through the individuals who
>participate in the IETF.
>
>Could you elaborate on why you believe "no" is the correct answer?

Richard said "ways to press", and I assumed that he meant what he 
said. I also assumed that he had read BCP 79. Nothing in BCP 79 
allows the IETF to press on someone who doesn't abide by it. BCP 79 
tells you how to comply with the IETF procedures of you want to. We 
(Continue reading)


Gmane