Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (KeyingMaterialExporters for Transport Layer Security (TLS)) toProposed Standard

From: Erick O <[email-masked]>
Date: Thu, 17 Sep 2009 23:37:06 -0700 (PDT)

________________________________
From: Jeffrey A. Williams <[email-masked]>
To: Wes Beebee (wbeebee) <[email-masked]>
Cc: [email-masked]; [email-masked]; Nicolas Williams <[email-masked]>; [email-masked]
Sent: Monday, July 27, 2009 5:39:23 PM
Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (KeyingMaterialExporters for Transport Layer Security (TLS)) toProposed Standard

Wes and all,

  Not entirely true here.  First use in commerce supersedes any
patent if the person of a product that didn't file a patent for it has
used it in commerce before another and can prove such that is
patenting the product or similar even some types of service has filed
the patent and it has been approved.  The problem with this scenario
is that one may not even know even with a through patent search if
such a patent has been filed, not to mention when, and so legal proceedings
may ensue as a result, costing both litigants significant $$.

  Standards should only set basic parameters by which any number
of products, in this fora a security product of some sort.  Products that
exceed the standard parameters should than be considered standardized.
Any standard that is set that does not is a bad standard.

"Wes Beebee (wbeebee)" wrote:

> Many patents are filed for defensive reasons.  Ie. If I don't patent it,
> then someone else will, and then I won't be able to use the idea I came
> up with.  The other defensive reason is so that if company A tries to
> sue company B for infringing patents, then company B can threaten to sue
> company A back - and the end result of the mutual assured destruction is
> that no one ends up suing anyone else.  In other words, patents can
> actually reduce the number of law suits out there.  In many cases,
> patents are filed long before the technology is standardized - and, if
> disclosed properly through the IETF process, can be weighed when
> determining whether to adopt a standard.  In some cases, the IETF may
> choose to adopt a patent-encumbered standard simply because it's
> technically superior to other options - and because the encumberence is
> not judged to be too much of a barrier to adoption.  One great way to
> find out if the patent is too much of a barrier would be to label the
> technology as "Experimental" with the experiment being whether anybody
> would implement it given the patent encumberence, and if enough people
> can implement it, striking the right deals, then the technology can move
> onto the standards track.
>
> - Wes
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard Stallman
> Sent: Thursday, July 23, 2009 9:38 PM
> To: Nicolas Williams
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying
> MaterialExporters for Transport Layer Security (TLS)) to Proposed
> Standard
>
>    The operative word here is uncertainty.  A patent-holder creates
>    uncertainty.  How should an SDO respond?  I'm not sure.  I'm only
> sure
>    that I don't like getting DoSed, either into dropping a standard or
> into
>    not implementing it for fear of infringing.
>
> That's the nature of software patents: each one denies people the
> freedom to write and run certain kinds of software.  This is why we must
> abolish software patents.
>
> Until we succeed in doing that, we can resist in certain ways.  One of
> them is to refuse to establish standards that encourage their use.
>
> Generally speaking, standards are useful, because they enable people to
> converge what they are doing.  But that ceases to be true when the use
> of the standard is patented.  It is better to have no standard than have
> a standard that invites people into danger.
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> Ietf-honest mailing list
> [email-masked]
> http://lists.iadl.org/mailman/listinfo/ietf-honest

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
  Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Erick O <[email-masked]>
Date: Thu, 17 Sep 2009 23:37:37 -0700 (PDT)

________________________________
From: Richard Stallman <[email-masked]>
To: Jeffrey A. Williams <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Sent: Friday, July 24, 2009 9:55:19 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard

I have never argued in favor of open source software.
I am a free software activist.

(See http://www.gnu.org/philosophy/open-source-misses-the-point.html.)
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Erick O <[email-masked]>
Date: Thu, 17 Sep 2009 23:34:46 -0700 (PDT)

________________________________
From: Lawrence Rosen <[email-masked]>
To: [email-masked]; Wes Beebee (wbeebee) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Sent: Wednesday, July 29, 2009 11:41:58 AM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard

I agree completely with Richard Stallman's responses to an earlier email. I
repeat the relevant parts of that earlier exchange below. This reflects a
basic policy that should be adopted by IETF. 
/Larry Rosen

********************* Email from RMS:

If you are claiming that one additional software patent can result in fewer
software patent infringement lawsuits, indeed that can sometimes be true.
But lawsuits are just the tip of the iceberg of the danger of patents.

When people decide not to distribute a program, or not to implement a
feature, because they fear they would be sued, no lawsuit occurs, but the
patent has done harm.

      In many cases,
    patents are filed long before the technology is standardized - and, if
    disclosed properly through the IETF process, can be weighed when
    determining whether to adopt a standard.

IETF should use this leverage to refuse to issue a standard unless the
companies in question allow it to be freely implemented and used.

      In some cases, the IETF may
    choose to adopt a patent-encumbered standard simply because it's
    technically superior to other options

That is an example of what not to do.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Stallman
Sent: Monday, July 27, 2009 9:37 PM
To: Wes Beebee (wbeebee)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying
MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard
<snip>

---

From: Erick O <[email-masked]>
Date: Thu, 17 Sep 2009 23:44:33 -0700 (PDT)

________________________________
From: Eric Rescorla <[email-masked]>
To: Florian Weimer <[email-masked]>
Cc: [email-masked]; Paul Hoffman <[email-masked]>; [email-masked]
Sent: Wednesday, July 22, 2009 6:51:36 AM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

At Wed, 22 Jul 2009 09:59:38 +0000,
Florian Weimer wrote:
> Anyway, those who object to the ECC infection should strive to remove
> it from the base TLS spec.  It doesn't make sense to rehash this
> discussion over and over again, for each draft produced by the WG
> which happens to be compatible with ECC algorithms and for which
> Certicom files an IPR claim.

Note: ECC isn't in the base spec, really. 

More precisely, the code points are defined in 4492. 

All the ECC that's defined in 5246 is the rules for what sorts of
certificates may be used for a given algorithm, and that's because
5246 changed the rules beyond 4346 and so we wanted to have them all
in one place.

-Ekr

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:33:08 -0700 (PDT)

________________________________
From: Erick O <[email-masked]>
To: Eric Rescorla <[email-masked]>; Florian Weimer <[email-masked]>
Cc: [email-masked]; [email-masked]; Paul Hoffman <[email-masked]>
Sent: Thursday, September 17, 2009 11:44:33 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

-Ekr

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:33:51 -0700 (PDT)

________________________________
From: Erick O <[email-masked]>
To: [email-masked]; Jeffrey A. Williams <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Sent: Thursday, September 17, 2009 11:37:37 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:34:04 -0700 (PDT)

________________________________
From: Erick O <[email-masked]>
To: Jeffrey A. Williams <[email-masked]>; Wes Beebee (wbeebee) <[email-masked]>
Cc: [email-masked]; [email-masked]; Nicolas Williams <[email-masked]>; [email-masked]
Sent: Thursday, September 17, 2009 11:37:06 PM
Subject: Re: [TLS] [Ietf-honest] Last Call: draft-ietf-tls-extractor (KeyingMaterialExporters for Transport Layer Security (TLS)) toProposed Standard

Wes and all,

Regards,

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:34:50 -0700 (PDT)

________________________________
From: Erick O <[email-masked]>
To: Lawrence Rosen <[email-masked]>; [email-masked]; Wes Beebee (wbeebee) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Sent: Thursday, September 17, 2009 11:34:46 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard

      In many cases,

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:40:28 -0700 (PDT)

________________________________
From: David Morris <[email-masked]>
To: [email-masked]; [email-masked]
Sent: Monday, July 27, 2009 6:34:54 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

On Thu, 23 Jul 2009, Richard Stallman wrote:

> Generally speaking, standards are useful, because they enable people
> to converge what they are doing.  But that ceases to be true when the
> use of the standard is patented.  It is better to have no standard
> than have a standard that invites people into danger.

An opinion with which I would differ ... patent encumbered documented behavior is ALWAYS better than no public documentation for commonly used protocols. As a person with frequent exposure to the operational troubleshooting side of networks, lack of accessible documentation is intolerable.

There is no trap when an SDO documents a protocol and publishes that documentation with a caveat that includes documentation of one or more patent claims related to the published protocol. Any fool who implements the protocol without resolving those issues deserves what the get. The trap is the case where the patent or other IP claim isn't revealed.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:40:41 -0700 (PDT)

________________________________
From: Wes Beebee (wbeebee) <[email-masked]>
To: [email-masked]; Nicolas Williams <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Sent: Monday, July 27, 2009 9:51:05 AM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard

- Wes

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:41:07 -0700 (PDT)

To: [email-masked]
Sent: Saturday, July 25, 2009 1:36:39 AM

Richard and all,

  Open source software for some uses does provide for some
utility.  By a opposite token, open source software for other
uses is an inhearent privacy and security risk for obvious reasons
so indeed such also misses the point.  I am in favor of any Good
free software, but not a proponent of all software being free of
course.  Free software is the choice of the creator, not of the
potential user.

Regards,

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:41:52 -0700 (PDT)

________________________________
From: Richard Stallman <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Sent: Thursday, July 23, 2009 6:37:54 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

    The operative word here is uncertainty.  A patent-holder creates
    uncertainty.  How should an SDO respond?  I'm not sure.  I'm only sure
    that I don't like getting DoSed, either into dropping a standard or into
    not implementing it for fear of infringing.

That's the nature of software patents: each one denies people the
freedom to write and run certain kinds of software.  This is why we
must abolish software patents.

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:44:54 -0700 (PDT)

________________________________
From: Jeffrey A. Williams <[email-masked]>
To: Matthew Campagna <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Wednesday, July 22, 2009 11:25:44 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (KeyingMaterial Exporters for Transport Layer Security (TLS)) toProposed Standard

Matthew and all,

  I don't and haven't assumed that Certicom has any "Protections" with
respect to any form or type of "TLS extractor".  But I for one am glad
that you have taken the time to clarify such as true.  I also have serious
doubts that Certicom has any Patent claim to ECC other than perhaps
your own specific product that may/does use ECC.  Could please clarify
that please?

Matthew Campagna wrote:

> In Hopes of Clarifying,
>
>    Since I filled out the form in question I would hope that you consider these comments with a little more weight than others' wild speculations about the intention of IPR #1154.
>
>    I do not read that IPR #1154 claims to have patents that cover the draft-ietf-tls-extractor, and perhaps more importantly, nor was it my intention to indicate any such claims.
>
>    I do recognize that it is listed in the section
>
>    IV. IETF Document or Other Contribution to Which this IPR Disclosure Relates:
>
>  I believe this to be correct as the free license being offered extends a license to use the following suites, to which we are making some claims,
>
>        A. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security(TLS)" RFC 4492, May 2006; or,
>        B. “TLS Elliptic Curve Cipher Suites with SHA‐256/384 and AES Galois Counter Mode,” RFC 5289, or
>        C. “Suite B Cipher Suites for TLS,” draft‐rescorla‐tls‐suiteb‐ 07.txt;
>
>  if one wants to use them in the draft-ietf-tls-extractor, under the conditions in a linked document.  Hence, I believe that the license is extending intellectual property rights that 'relates' to draft-ietf-tls-extractor.  I do not equate 'relates' to claiming rights over.
>
>  I do read that IPR #1154 claims to have patents that cover parts of documents listed in,
>
>    V  Disclosure of Patent Information (i.e., patents or patent applications required to be disclosed by Section 6 of RFC 3979)
>
>      C If an Internet-Draft or RFC includes multiple parts and it is not reasonably apparent which part of such Internet-Draft or RFC is alleged to be covered by the patent information disclosed in Section V(A) or V(B), it is helpful if the discloser identifies here the sections of the Internet-Draft or RFC that are alleged to be so covered:
>
>  Where it lists:
>
>  RFC 3278, RFC 4109, RFC 4492, RFC 4753, RFC 4754, RFC 4869, RFC 5008, RFC 5289, draft-rescorla-tls-suiteb-12, draft-green-secsh-ecc-07, draft-igoe-secsh-suiteb-00, draft-ietf-smime-3278bis-07,
> draft-ietf-smime-sha2-11
>
>  Note that draft-ietf-tls-extractor is not listed in the I-D or RFCs part of which the listed patents claim to cover.
>
> Therefore a reasonable person should be able to conclude that the statement is not making a claim that patents listed cover parts of the draft-ietf-tls-extractor.
>
>  As stated prior, I think the form being used creates the confusion at hand.  There is no clear definition of what should be in section IV versus section V. C.  Should more exact language be added to the form, I would be happy to update the IPR statement to help remove some stated uncertainties.
>
>  Further the RFC 3979 indicates the following:
>
> 6.3.  How Must a Disclosure be Made?
>
>    IPR disclosures are made by following the instructions at
>    http://www.ietf.org/ipr-instructions.
>
> A link I think most will find particularly amusing.
>
> Regards,
>    Matt
>
> Matthew Campagna | Director, Certicom Research
> Certicom Corp. | A Subsidiary of Research In Motion Limited
>
> [email-masked]
> direct        203.894.9777
> mobile        203.240.1269
> www.certicom.com
>

Regards,

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:46:36 -0700 (PDT)

________________________________
From: Florian Weimer <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]; [email-masked]
Sent: Wednesday, July 22, 2009 2:59:38 AM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

* Paul Hoffman:

> At 3:15 PM -0400 7/20/09, Dean Anderson wrote:
>>I am against this standard because of its patent encumbrances and
>>non-free licencing terms.
>
> In the past, I think that Dean Anderson has stated that he is not a
> lawyer (although I can't find the specific reference). Note that the
> statement above is legal advice: he is saying that a particular
> protocol is encumbered. Readers of this thread may or may not want
> to listen to his legal advice.

Eh, no.  It's a recommendation not to publish the draft as an RFC.
It does not even voice a legal opinion.

I really don't see what this is about.  Certicom is pretty close to
making the IETF process pointless, by overzealous filing of IPR
claims.  But apparently, there was a recent clarification that this
key agreement extension is only affected by Certicom's IP if it's used
with ECC, so it's hard to argue that Certicom is carrying out a denial
of service attack on the WG.

> That statement did not say "we have a patent that encumbers the
> specific documents in question".

The IETF process doesn't reward IPR holders for precise IPR
statements.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH      http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe            fax: +49-721-96201-99
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:48:04 -0700 (PDT)

________________________________
From: Nikos Mavrogiannopoulos <[email-masked]>
To: Dan Harkins <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Sent: Tuesday, July 21, 2009 7:48:53 AM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

I'd propose to add this text to the standard:
This protocol MUST NOT be used with RFC4492, RFC5289 and
draft-rescorla-tls-suiteb.

That way the certicom's patents are not applicable.

On Mon, Jul 20, 2009 at 11:24 PM, Dan Harkins<[email-masked]> wrote:
>
>  Certicom's IPR statement dated 13 October 2008 lists some patents
> that "may be necessary and essential to implementations of..." the
> TLS extractor draft "when used with either: " RFC4492, RFC5289
> or draft-rescorla-tls-suiteb. Check it out:
>
> http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf
>
>  Don't use it with RFC4492, RFC5289 or draft-rescorla-tls-suiteb and
> then the IPR statement does not apply. If it's possible to use the TLS
> extractor draft in a way that the IPR statement doesn't apply then I
> don't think you can say "the TLS Extractor draft is patent-encumbered".
>
>  I support free software* and I have no problem with this draft being
> advanced as a Proposed Standard.
>
>  regards,
>
>  Dan.
>
> * http://www.lounge.org/siv_for_openssl.tgz is a free version of RFC5297
>  for OpenSSL, and check out the "authsae" project on Source Forge.
>
> On Mon, July 20, 2009 12:15 pm, Dean Anderson wrote:
>> non-free licencing terms.  The working group did not get any clear
>> answers on what particular patents this draft may infringe, but a patent
>> holder (Certicom) did assert an IPR disclosure (1004) listing many
>> patents.  We have no alternative but to accept the Certicom disclosure
>> statements as meaning that the TLS Extractor draft is patent-encumbered
>> without a universal, free defensive license.
>>
>> The statement by https://datatrackerietf.org/ipr/1004/ referring to
>> http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf
>> which states:
>>
>>   "Certicom will, upon request, provide a nonexclusive, royalty free
>> patent license, to manufacturers to permit end users (including both
>> client and server sides), to use the patents in schedule A when
>> implementing any of these protocols, including those requiring third
>> party certificates provided the certificate is obtained from a licensed
>> Certificate Authority (CA). This license does not cover the issuing of
>> certificates by a Certification Authority (CA)."
>>
>> That is not a free license, since Certicom must respond to the "request"
>> before any license is granted. After the IETF finally approves the
>> necessary standards, Certicom is free to stop approving the requests.
>>
>> I ask others who support free software to join me in opposing this
>> document by sending a message stating opposition to the [email-masked]
>> mailing list.  IETF participation is open to the public, and anyone may
>> voice their view on IETF standards.  It is also substantive to oppose a
>> document because of its patent status, and in fact, any topic that is
>> considered during or related to the IETF process is substantive.
>>
>>               --Dean
>>
>>
>> On Mon, 20 Jul 2009, The IESG wrote:
>>
>>> The IESG has received a request from the Transport Layer Security WG
>>> (tls) to consider the following document:
>>>
>>> - 'Keying Material Exporters for Transport Layer Security (TLS) '
>>>    <draft-ietf-tls-extractor-06.txt> as a Proposed Standard
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits
>>> final comments on this action.  Please send substantive comments to the
>>> [email-masked] mailing lists by 2009-08-10. Exceptionally,
>>> comments may be sent to [email-masked] instead. In either case, please
>>> retain the beginning of the Subject line to allow automated sorting.
>>>
>>> The file can be obtained via
>>> http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt
>>>
>>>
>>> IESG discussion can be tracked via
>>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16821&rfc_flag=0
>>>
>> Av8 Internet   Prepared to pay a premium for better service?
>> www.av8.net         faster, more reliable, better service
>> 617 344 9000
>>
>>
>>
>>
>>
>>
>>

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:51:30 -0700 (PDT)

________________________________
From: Nicolas Williams <[email-masked]>
To: Dean Anderson <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Sent: Tuesday, July 21, 2009 12:50:28 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

On Mon, Jul 20, 2009 at 04:54:36PM -0400, Dean Anderson wrote:
> Its possible to use any draft as toilet paper---a use that doesn't 
> infringe---but that doesn't mean the draft is free and unencumbered.

The IPR applies to ECC, so don't use ECC.  I don't see
draft-ietf-tls-extractor as explicitly encumbered, but as encumbered
when used with ECC, and in encumbered ways.  But see below.

> It is not the patents on these other standards that are the problem with
> TLS-extractor.  It is that using the methods described in the extractor
> draft further infringe patents owned by Certicom.  So we should either
> use other methods, or require that Certicom offer a suitable license.

Arguably any IPR claim on draft-ietf-tls-extractor based on ECC IPR is
wrong: if you infringe on the ECC IPR then use of
draft-ietf-tls-extractor does not make this infringement worse.

The interesting question is:

    Suppose you have an implementation of TLS that has a license to
    Certicom's ECC IPR, and suppose that you have an application that
    uses draft-ietf-tls-extractor, and the application does not have its
    own license to Certicom's ECC IPR -- is the application then
    infringing on Certicom's IPR??

IANAL and will not speculate as to what the answer to that is.  Each TLS
implementor should get their own legal advice on this question.

However if the answer is yes, then the TLS implementation must not
export the TLS extractor to applications when doing so would cause the
applications to infringe.  That might make the APIs obnoxious (apps
would have to indicate what IPR they've licensed, if any), but the
result would still be useable and useful.

IMO draft-ietf-tls-extractor should progress.  TLS implementors may want
to get legal advice as to whether draft-ietf-tls-extractor APIs puts
third-party applications at risk, and if so how they should communicate
this risk to third-parties.  Such a note might well belong in the RFC
itself.

Ideally Certicom would say that draft-ietf-tls-extractor does not put
applications at risk of infringment regardless of whether ECC cipher
suites [that could infringe on Certicom IPR] are in use.  But
draft-ietf-tls-extractor should proceed even without such a statement.

Nico

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:45:13 -0700 (PDT)

________________________________
From: Matthew Campagna <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Wednesday, July 22, 2009 6:49:42 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

In Hopes of Clarifying,

  Where it lists:

Regards,
  Matt

[email-masked]                      
direct        203.894.9777                                                      
mobile        203.240.1269
www.certicom.com

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:52:14 -0700 (PDT)

________________________________
From: Dan Harkins <[email-masked]>
To: Dean Anderson <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Sent: Monday, July 20, 2009 1:24:44 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

  regards,

  Dan.

---

From: Erick O <[email-masked]>
Date: Fri, 18 Sep 2009 07:46:57 -0700 (PDT)

________________________________
From: Jeffrey A. Williams <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Todd Glassy <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Sent: Tuesday, July 21, 2009 4:41:39 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard

Nic and all,

  What is suggested here is not a reasonable solution or rational
suggestion.  I use ECC and was an early supporter of ECC.  Our
ECC product exceeds the current IETF standards track.  We will
continue to use ECC and improve on our ECC product as we see
fit.  The IPR, like FISMA, is misguided as thankfully the recent GAO
report clearly pointed out.

Regards,