Subject: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 20 Jul 2009 09:48:16 -0700 (PDT)

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

---

From: Dean Anderson <[email-masked]>
Date: Mon, 20 Jul 2009 15:15:53 -0400 (EDT)

I am against this standard because of its patent encumbrances and
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:

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

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Mon, 20 Jul 2009 16:54:36 -0400 (EDT)

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.

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.

If we find ways to implement those other standards without infringing
patents, we would still be caught by TLS-extractor.  So it is imperative
to avoid that trap.  

		--Dean

On Mon, 20 Jul 2009, Dan Harkins 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:
> 
>   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:

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 20 Jul 2009 13:24:44 -0700 (PDT)

regards,

  Dan.

---

From: Douglas Stebila <[email-masked]>
Date: Tue, 21 Jul 2009 18:32:21 +1000

I have implemented draft-ietf-tls-extractor-06 in the TLS v1.0  
implementation in OpenSSL.  I found the draft easy to implement with  
no ambiguities or concerns.  I believe that the functionality provided  
by the draft will be extremely valuable for building application-level  
security protocols and encourage its standardization.

It is my interpretation of the draft that it can be implemented in any  
version of TLS, not just TLS v1.2.  Obviously the derived key may be  
different if the underlying TLS PRF is defined differently (as it is  
for TLS v1.2), but the draft is still well-defined for previous  
versions of TLS.

For those interested in the OpenSSL implementation, I have posted a  
page on my website with the patch.
	http://www.douglas.stebila.ca/code/keying-material-exporters/
In addition to a patch for OpenSSL, I have also done patches to Apache  
and PHP to expose a PHP function that allows a PHP application to  
derive keying material from the underlying TLS connection according to  
the draft specification.

Douglas

---

From: Dean Anderson <[email-masked]>
Date: Tue, 21 Jul 2009 10:35:27 -0400 (EDT)

Hi Douglas,

OpenSSL has implemented patented technology before, and distributed it
without license but with statement that it contained patented technology
that users weren't licenced to use.  While challenging the law can
sometimes be a good thing and no criticism of OpenSSL project is
intended, their actions do not improve our licensing options.  For many
years, I had to purchase Stronghold--a licensed version of OpenSSL.  

However easy these patented standards are to implement, they remain
patented.  And we continue to have the right in the IETF process to
demand other, non-patented alternatives, and reject those standards that
don't have suitable licensing terms.  RFC3979 requires the WG to
consider non-patented alternatives, and that didn't happen.

		--Dean

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 21 Jul 2009 17:48:53 +0300

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.

---

From: Martin Rex <[email-masked]>
Date: Tue, 21 Jul 2009 17:32:30 +0200 (MEST)

> draft-rescorla-tls-suiteb.

How much longer are we going to beat that dead horse?

I'm not aware of information that the Certicom patents apply to
TLS extractors.

I'm not even aware of information that Certicom claims that the
patent applies to TLS extractors when ECC crypto is used.

The information that I've seen is that the Certicom patent claim
"covers" TLS extractors when TLS is used with ECC crypto, and
they acutally imply that their patents claims "cover" pretty much all
standards around TLS when TLS is used with ECC crypto.

TLS extractors is essentially the TLS PRF exposed with an API,
so really, for IP lawyers, TLS with extractors has the exact same
attack surface as TLS without TLS extractors.

-Martin

---

From: Dean Anderson <[email-masked]>
Date: Tue, 21 Jul 2009 11:58:32 -0400 (EDT)

I think you misunderstand how patents work or what the license says.

The licence is available for the case "when used with either ...". It is
not the case that a patent only applies to specific RFCs.  RFC's aren't
mentioned in patents. Patent claims covering tls-extractor very likely*
apply to any use of extractor, not just those uses that also use other
Certicom technology in other RFCs.  I think you are assuming that
because Certicom offers a license for a certain situation (or maybe 'use
configuration' is a better phrase), that different use configurations
then won't need a license, but that isn't usually* the case. Those other
'use configurations' that infringe a claim still require a license.

Note also the Certicom license isn't available for use by Certificate
Authorities.

But note also that identifying the specific claims is not the best
approach for developing non-infringing technology. One starts with prior
art which cannot be patented. So the question to ask yourself is:

  "How difficult would it be to start from unpatentable prior art, and
  produce something that does what is needed, but differently from how
  Certicom et al did it?"

Except for some very fundamental technology, the answer is almost always
"Easy". The alternative is to pay license fees, create more income for
patented standards, and encourage even more patenting of standards.  
So, please, just say "no", and oppose this document.

                --Dean

[* Can't say for certain because Certicom has been unhelpful with
specific claims, and the bulk of patents is large--I've read some, but
not all.]

---

From: Dean Anderson <[email-masked]>
Date: Tue, 21 Jul 2009 12:38:28 -0400 (EDT)

On Tue, 21 Jul 2009, Martin Rex wrote:

> I'm not aware of information that the Certicom patents apply to TLS
> extractors.
> 
> I'm not even aware of information that Certicom claims that the patent
> applies to TLS extractors when ECC crypto is used.

Actually, you are "aware" of these patents by any reasonable standard,
because you are "aware" of IPR disclosure 1004 and you are "aware" of at
least this discussion informing you of the patents.  Willfully
disregarding the patent notices does not make you "unaware", but just
serves to discredit any defense your lawyer might raise against charges
of intentional infringement.  To put it as plainly as possible, if the
demand letter from the patent holder isn't the first time you heard of
the patent, you might have a problem with intentional infringement. At
that point, it is often too late to challenge the validity of the
patent.

> "covers" TLS extractors when TLS is used with ECC crypto, and they
> acutally imply that their patents claims "cover" pretty much all

Some of their patents are indeed very broad in scope.

> TLS extractors is essentially the TLS PRF exposed with an API, so
> really, for IP lawyers, TLS with extractors has the exact same attack
> surface as TLS without TLS extractors.

If this is an argument against the validity of a patent, you should
bring it to the patent office. This body cannot challenge the validity
of a patent.  Except in certain circumstances, a court cannot challenge
the validity of a patent.

It is unwise to ignore a patent, since a court is to presume the
validity of a patent.  Court cases, like Bilsky, that invalidate a
patent, invalidate a whole class of patents when their reasoning is
statutory or constitutional. (Bilsky is statutory and if upheld, may
invalidate all software patents--unless Congress alters the law)  When
one wins an ordinary patent case, it is usually a factual matter that
the claims don't actually cover the use, or the other party has
committed some misconduct (eg. Qualcomm v. Broadcomm).  That you think
the patent is a bad patent that should never have been granted isn't a
valid legal reason to ignore a patent.

		--Dean

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Jul 2009 09:43:33 -0700

At 3:15 PM -0400 7/20/09, Dean Anderson wrote:
>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.

>  The working group did not get any clear
>patents.

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

>  We have no alternative but to accept the Certicom disclosure

Who is "we"? Dean Anderson is not a leader in the IETF, nor of the TLS protocol or developer community. "We" have plenty of alternatives, for almost any value of "we" that make sense here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Tue, 21 Jul 2009 18:48:48 +0200 (MEST)

The Certicom IPR disclosure says that their patent claims cover
pretty much all of the TLS documents when TLS is used with ECC Crypto.

You're constantly arguing that Certicoms patent claims *APPLY*
to TLS extractors -- which it is not, and which no one from
Certicom seems to claim.  

The difference between "covers" and "applies" is, that the
TLS extractors technology does not, by itself, infringe on any of
the patent claims in their patents--otherwise, there would not be
the precondition with the use of ECC crypto.

-Martin

---

From: Dean Anderson <[email-masked]>
Date: Tue, 21 Jul 2009 15:33:23 -0400 (EDT)

On Tue, 21 Jul 2009, Paul Hoffman wrote:

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

My statement above is not legal advice.  I am not a lawyer, and have not
claimed to be a lawyer. I am the President of the League for Programming
Freedom (LPF), which opposes software patents, and have been involved
with the LPF since 1989.  I am a member of the Boston Social Law Library
and I also have access to lawyers and extensive legal materials.  

I've heard variations of Paul Hoffman's accusations above from people
who want to to advocate their own position by encouraging people to
ignore indisputable facts or by advocating disregard the law in some
cases.  I first heard that claim when I told a network admin that the
newsgroup alt.sex.pedophilia shouldn't be carried because it is used for
distributing child pornography. The admin wrote back asserting that he
would report me to the bar association for practicing law without a
license.  I did contact a lawyer; stating facts, opinion, and my
position are not legal advice and are not the practice of law without a
license. Paul's claims here are false. Please ignore them.

> specific documents in question".

Yes, it does indeed state that. That's what an IPR statement discloses,
and IPR 1004 lists this document, and cites the patents.

> > statements as meaning that the TLS Extractor draft is
> > patent-encumbered without a universal, free defensive license.
> 
> Who is "we"? Dean Anderson is not a leader in the IETF, nor of the TLS
> protocol or developer community. "We" have plenty of alternatives, for
> almost any value of "we" that make sense here.

Paul Hoffman is also not the leader of the IETF, and of course, "we" as
used by both Paul and myself does not mean that either of us speak for
the IETF.  I used "we" just as Paul used it.  Paul's objection to "we"
has no relevance. Please ignore it.

However, contrary to Paul's assertion that '"we" have many
alternatives', there are in fact only two alternatives available to the
IETF at present:  Either approve the document with its licencing terms
as-is, or reject the document.  I argue, on a firm factual basis, for
rejecting that document.

		--Dean

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Jul 2009 14:50:28 -0500

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

> 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: Dean Anderson <[email-masked]>
Date: Tue, 21 Jul 2009 16:15:54 -0400 (EDT)

> to TLS extractors -- which it is not, and which no one from

Certicom claimed this when they added TLS extractor to IPR 1004.

> The difference between "covers" and "applies" is, that the TLS
> extractors technology does not, by itself, infringe on any of the
> patent claims in their patents--otherwise, there would not be the
> precondition with the use of ECC crypto.

There is no factual basis for your statement. The terms to which you
refer are in the _license_, which is distinct from the patents.  But In
order to add this document to the license, they should have a patent
claim somewhere that covers extractor, otherwise they would be subject
to a claim of misuse by trying to extend the patent to non-patented
components.  Certicom has an army of lawyers, and I have no reason to
think they would overlook that. You have provided no factual statements
to back up your assertion that they don't have patent coverage on
extractor.

============= Quote
 "Misuse" means that the patent owner has over-reached and tried to do 
more than legitimately is authorized by the patent monopoly. This can 
involve more than just patent law, for the abuse of a legal monopoly 
easily become a forbidden monopoly prohibited by the antitrust laws. But 
somewhere between legitimate use and antitrust violation lies a  wide 
range of acts that, although not so gross as to constitute antitrust 
violations, are nevertheless abuses of the patent right for which the 
penalty is temporary loss of the patent privilege. [...] 

 Misuse is the "attempt to 'extend the patent' and thus monopolize the
market for the unpatented component." Rohm & Hass Co. v. Dawson Chemical
Co. (1979) 

============= End Quote
Section 8.7, pg 137, "Intellectual Property, Patents, Trademarks and
Copyright"  by Arther Miller and Michael Davis (1990)

I see no reason to assume there is no patent coverage on TLS extractor.

		--Dean

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 22 Jul 2009 00:29:09 +0300

> 'use configurations' that infringe a claim still require a license.

After this clarification I would object draft-ietf-tls-extractor to be
published as proposed standard.

regards,
Nikos

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 21 Jul 2009 16:33:41 -0700

Dean, Paul, and all,

  Sorry Paul but in this instance I have to agree with Dean, I
didn't see anything in his previous remarks that constituted legal
advice, and I DO have a law degree but do not practice law.

  I also agree with Deans previous remarks that the standard
indeed is patent incumbered.  Such incumbrences may/will
price many small companies out of the market which is not a
economically or socially healthy thing.

> as-is, or reject the document.  I argue, on a firm factual basis, for

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

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 21 Jul 2009 16:41:39 -0700

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,

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 21 Jul 2009 19:12:29 -0700

Nikos and all,

  I concur.

Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Jul 2009 18:40:50 -0700

At Mon, 20 Jul 2009 15:15:53 -0400 (EDT),
> without a universal, free defensive license.

This isn't really a complete description of the situation.

As others have stated, Certicom's has a variety of patents that
apply to ECC technology. When TLS Extractor (or indeed any other
IETF technology) is used with the TLS ECC cipher suites, then
there is a potential issue with regard to Certicom's patents,
but that issue is produced not by Extractor, but by the use
of ECC. After Certicom's disclosure (1004), there were
questions about whether Certicom's IPR also applied to Extractor
with non-ECC cipher suites.

During this discussion, Certicom posted a clarification:
http://www.ietf.org/mail-archive/web/tls/current/msg03508.html

    It is our intention to foster broad adoption of ECC technology.  The
    grant is meant to cover any necessary Certicom patents and patent
    applications to implement RFC 4492, RFC 5289 or the
    draft-rescorla-tls-suiteb when used with draft-ietf-tls-extractor.  It
    is not making any statement to the draft-ietf-tls-extractor when used
    absent of these three cipher suites.

You can find the new disclosure at: https://datatracker.ietf.org/ipr/1153/.

In addition, Certicom posted:
(see also http://www.ietf.org/mail-archive/web/tls/current/msg03526.html),
which reads in part:

   Section V of the form, "Disclosure of Patent Information (i.e.,
   patents or patent applications required to be disclosed by Section 6
   of RFC 3979)," has been updated.  Subsection C highlights the specific
   RFCs and I-Ds that are believed to be covered by the patents and
   patent applications listed in Schedule A of the linked IPR
   contribution
   (http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf).
   Please note that no version of the draft_ietf_tls_extractor appears in
   this section.

I consider this pair of statements combined with the IPR statement quite
satisfactory. You of course are free to feel differently.

-Ekr

---

From: Florian Weimer <[email-masked]>
Date: Wed, 22 Jul 2009 09:59:38 +0000

* Paul Hoffman:

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

> specific documents in question".

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

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.

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Jul 2009 06:51:36 -0700

At Wed, 22 Jul 2009 09:59:38 +0000,
> 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: Dean Anderson <[email-masked]>
Date: Wed, 22 Jul 2009 15:26:54 -0400 (EDT)

Hi Eric,

> with non-ECC cipher suites.

Err, no. See the message on the misuse of patents.  IF* there is no
patent claim to cover extractor, adding extractor would raise the issue
of misuse for trying to cover extractor with its patent licence.  IF*
there is a claim or claims covering extractor, we cannot be sure they
are limited to use with ECC.  The test for infringement is when the use
performs "substantially the same function" as claimed.  It would seem
that anything that is similar to ECC, (but not ECC) probably performs
substantially the same function with respect to extractor claims.

[* Again, more exact statements cannot be made because Certicom has been
unhelpful in identifying the precise patent(s) and claims that cover
extractor.]

> You can find the new disclosure at: https://datatracker.ietf.org/ipr/1153/.

Then they updated that with IPR 1154. While necessary updates of
details, I find no differences that significantly alter the key facts:

1. The Certicom disclosures state that Extractor is covered by a patent.

2. There is no universal free license. There is only the offer to 
request a free license. Certicom can refuse requests at anytime.

3. Certificate Authorities are already denied any free licence.

The statement you quote above doesn't alter anything, and I am mystified
why people continue to cite that statement as evidence of "good intent"
or that this is free software. It is not free software. Obviously,
_every_ proprietary software vendor's intention is to 'foster broad
adoption' of their technology. They often give out free samples to do
that.  And of course, they then extract as much money for that software
as they can;  the software doesn't remain free.  Certicom's stated
intent is to foster broad adoption, not produce free software.

But the Certicom statement is still slightly misleading because there is
no actual grant made in the document, even though the document refers to
"the grant".  The document states only that one may _request_ a free
license. But one doesn't need a 'grant' to request free licence. Anyone
can _ask_ Oracle, MS, etc for a free license too---Maybe that request
will be granted.  And BTW, I have no doubt that Certicom will give out
_some_ free licenses to encourage adoption---I'm not accusing them of
outright deception.  But proprietary vendors like Oracle also give out
free samples.  The difference is that free software is inherently free,
and proprietary software is free for a limited time.  Don't be fooled by
the limited offer.

> satisfactory. You of course are free to feel differently.

The Certicom statements are satisfactory only in the sense that Certicom
has met the minimum requirements for disclosure.  Once the disclosure
content is analyzed for their terms, I find the terms offered
unacceptable and recommend against approving the document.

But I think the process is not satisfactory because the Working Group
didn't discuss non-patented alternatives to extractor as mandated by RFC
3979.  If the WG did discuss non-patented alternatives, I missed that
discussion, and I would appreciate a pointer to the record.

		--Dean

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Jul 2009 21:31:44 +0200

With the caveat that I have recently returned from vacation, and
consequently may have missed some clarifications or paged out some
context:

If the #1154 IPR disclosure is the final word from Certicom on this
document, I don't support advancing this document on the standards
track.  My concern remains that Certicom claims they have IPR that
covers the document -- that is what the #1154 disclosure says (section
IV).  The additional information provided in the PDF is not helping: it
grants a license for use together with ECC.  It doesn't say anything
about the use without ECC.

The way I see it, TLS implementers and the broader Internet does not
gain something significant by having this document published.  Other
IETF documents can use the TLS PRF to derive keying material.  On the
contrary, it seems both TLS implementers and the broader Internet
community would be hurt by publishing the document since having patent
threats looming over widely used techniques has stability and
interoperability impacts.

I recall that Certicom was positive about clarifying their intentions so
maybe we can continue that discussion and get something more useful than
the recent disclosure.

Speaking as TLS implementer of the document and document [1] author that
reference this document,
/Simon

[1] http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 22 Jul 2009 13:57:12 -0700

While I see that draft-ietf-tls-extractor is listed in section IV of
#1154 IPR disclosure as related material,  I see that it is explicitly
not listed in section V part C which lists what is specifically covered
by the disclosure.  I don't think Certicom is claiming IPR on
draft-ietf-tls-extractor because it is not among the list of documents
in section V.   

Joe

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Simon Josefsson
> Sent: Wednesday, July 22, 2009 12:32 PM
> To: [email-masked]; [email-masked]
> Subject: Re: Last Call: draft-ietf-tls-extractor (Keying 
> Material Exportersfor Transport Layer Security (TLS)) to 
> Proposed Standard
> 
> With the caveat that I have recently returned from vacation, 
> and consequently may have missed some clarifications or paged out some
> context:
> 
> If the #1154 IPR disclosure is the final word from Certicom 
> on this document, I don't support advancing this document on 
> the standards track.  My concern remains that Certicom claims 
> they have IPR that covers the document -- that is what the 
> #1154 disclosure says (section IV).  The additional 
> information provided in the PDF is not helping: it grants a 
> license for use together with ECC.  It doesn't say anything 
> The way I see it, TLS implementers and the broader Internet 
> does not gain something significant by having this document 
> published.  Other IETF documents can use the TLS PRF to 
> derive keying material.  On the contrary, it seems both TLS 
> implementers and the broader Internet community would be hurt 
> by publishing the document since having patent threats 
> looming over widely used techniques has stability and 
> I recall that Certicom was positive about clarifying their 
> intentions so maybe we can continue that discussion and get 
> something more useful than the recent disclosure.
> 
> Speaking as TLS implementer of the document and document [1] 
> author that reference this document, /Simon
> 
> [1] 
> http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02
> 
> > 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.
> >
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Jul 2009 23:26:41 +0200

Let's go back to RFC 3979:

  6.4.  What Must be in a Disclosure?

  6.4.1.  The disclosure must list the numbers of any issued patents or
   published patent applications or indicate that the claim is based on
   unpublished patent applications.  The disclosure must also list the
   specific IETF or RFC Editor Document(s) or activity affected.

The "draft-ietf-tls-extractor-06" name is mentioned in the disclosure.

For what it's worth, the PDF referenced in the disclosure also mentions
draft-ietf-tls-extractor-06.

Together, I can't read this in any other way that Certicom believes they
have some patents covering draft-ietf-tls-extractor-06 and have followed
the RFC 3979 rules and informed the IETF about this.

If Certicom didn't intend to claim they believe they own patents that
they believe covers draft-ietf-tls-extractor-06 they need to supersede
the disclosure with one that does not mention that document.

The reason for this situation may be the poor terminology used by the
IETF IPR web pages.  I understand and appreciate that Certicom has tried
to clarify the situation, but to me the updated form does not improve
the situation.  Perhaps Certicom would be able to more easily create a
disclosure that matches RFC 3979 rules if the web pages were improved.

/Simon

---

From: Dean Anderson <[email-masked]>
Date: Wed, 22 Jul 2009 17:57:29 -0400 (EDT)

If your interpretation were correct, then we would have to say that
Certicom is not claiming IPR on _any_ IETF document---draft or
RFC---since none are listed in Section V. But I think that is obviously
incorrect---I think you have misinterpreted what should be in which
section.

Section titles and descriptions: 

 Section IV. IETF Document or Other Contribution to Which this IPR 
 Disclosure Relates: 

 Section V. Disclosure of Patent Information (i.e., patents or patent 
 applications required to be disclosed by Section 6 of RFC 3979)

Section IV lists the drafts and RFCs.  Section V lists the patents.  
One would not expect to find a draft or RFC listed in Section V, nor a
patent listed in Section IV.

Extractor and other documents are listed in section IV. 

		--Dean

---

From: Richard Stallman <[email-masked]>
Date: Wed, 22 Jul 2009 18:21:26 -0400

The IPR applies to

Since we're talking about patents, calling them "IPR"
just introduces gratuitous vagueness.  Patent law and copyright
law have very little in common, so lumping them together is
basically a mistake.  And there are a dozen other areas of laws
which you're generalizing about each time you say "IPR".

See http://www.gnu.org/philosophy/not-ipr.html for more explaation
of why the term "intellectual property" is harmful.

If you call them "patents", it takes 4 more characters and
avoids the confusion.  So the real question is this:

    Suppose you have an implementation of TLS that has a license to
    Certicom's ECC patents, 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 patents -- is the application then
    infringing Certicom's patents?

(An analogous question about copyrights would not be meaningful
or interesting, because copyright does totally different things.)

I don't know the answer to that question, but I can follow you in
considering the consequences of a possible yes answer.

    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.

There is no technical way that the TLS implementation can tell whether
the application has a patent license.  That could be changed from the
day to the next, by the actions of lawyers and businessmen, without
any change in the code of the application.

So the question that would follow is, what good is a standard which
people are free to implement in a library, but cannot actually use
without asking permission?

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 22 Jul 2009 15:31:01 -0700

I agree with Simon that the IETF's disclosure page could use some work,
it seems rather confusing and it is not consistently filled out.

Comments inline below:   

> If your interpretation were correct, then we would have to 
> say that Certicom is not claiming IPR on _any_ IETF 
> document---draft or RFC---since none are listed in Section V. 
> But I think that is obviously incorrect---I think you have 
> misinterpreted what should be in which section.
>

[Joe] Are we both looking at https://datatracker.ietf.org/ipr/1154/?  In
section V I see several documents listed:

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

>  Section IV. IETF Document or Other Contribution to Which 
> this IPR  Disclosure Relates: 
> 
>  Section V. Disclosure of Patent Information (i.e., patents 
> or patent  applications required to be disclosed by Section 6 
> of RFC 3979)
> 
> One would not expect to find a draft or RFC listed in Section 
> V, nor a patent listed in Section IV.
> 

[Joe] Section V also has a sub-section C, which allows you to specify
what parts of IETF documents are covered by the patent information
disclosed in section V.  This section lists several documents which is a
subset of what is mentioned in section IV.  This seems straight forward
to me.  

Joe
> > not listed in section V part C which lists what is specifically 
> > covered by the disclosure.  I don't think Certicom is 
> claiming IPR on 
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Simon Josefsson
> > > Subject: Re: Last Call: draft-ietf-tls-extractor (Keying Material 
> > > Exportersfor Transport Layer Security (TLS)) to Proposed Standard
> > > 
> > > covers the document -- that is what the
> > > #1154 disclosure says (section IV).  The additional information 
> > > provided in the PDF is not helping: it grants a license for use 
> > > together with ECC.  It doesn't say anything about the use without 
> > > ECC.
> > > 
> > > IETF documents can use the TLS PRF to derive keying material.  On 
> > > the contrary, it seems both TLS implementers and the broader 
> > > Internet community would be hurt by publishing the document since 
> > > having patent threats looming over widely used techniques has 
> > > stability and interoperability impacts.
> > > 
> > > Speaking as TLS implementer of the document and document 
> [1] author 
> > > that reference this document, /Simon
> > > 
> > > [1]
> > > 
> > > > The IESG has received a request from the Transport 
> Layer Security 
> > > > WG
> > > > 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 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&d
> > > Ta
> > > > g=16821&rfc_flag=0

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 22 Jul 2009 17:36:23 -0500

> without asking permission?

I agree.  The question is: must each participant go pay a lawyer to
answer that question?  But suppose that we simply say that the very fact
that this question is raised is enough to drop the standardization
effort (e.g., because not every participant, in a volunteer organization
like the IETF, can pay for a lawyer every time something like this comes
up), are we not then making it trivial to DoS the standards process?

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.  In this case Mr. Campana
sent a clarification with a specific claim, but not disclaiming other
potential claims.  To me that's sufficient to proceed.  But IANAL, and I
don't represent my employer (as is the norm at the IETF).

Nico
--

---

From: Dean Anderson <[email-masked]>
Date: Wed, 22 Jul 2009 19:51:21 -0400 (EDT)

> draft-ietf-smime-sha2-11"

You are refering to Section V.C: 

====================
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:  
 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
====================

Section V.C of IPR 1154 is probably not filled out correctly since it
just states the document name. As you can see from the instructions, the
purpose of Section V.C is to clarify which /sections/ of documents are
covered, and no sections of documents are identified.

Section V.C is only needed if there are sections of a document that need
identification because it is not reasonably apparent which sections are
covered by patent.

By not putting a document in Section V.C, all that is indicated is that
it is 'reasonably apparent' which sections are covered by patent.

Excluding a document (tls-extractor) from Section V.C doesn't mean that
it isn't covered by a patent, it only means that it should be reasonably
apparent which sections of the document are covered.  The fact of patent
coverage is indicated by the presence of the document in Section IV.

		--Dean

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 22 Jul 2009 20:21:41 -0700

Dean and all,

  I believe that you are correct here Dean.  Further it seems to me that
Certicom is in a round about way attempting to claim a near manopoly
on Extractor technology.  If so, I have no doubt that they will face
serious challanges to such a claim.

Regards,

---

From: Matthew Campagna <[email-masked]>
Date: Wed, 22 Jul 2009 21:49:42 -0400

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

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 22 Jul 2009 23:25:44 -0700

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?

Regards,

---

From: Dean Anderson <[email-masked]>
Date: Thu, 23 Jul 2009 12:45:33 -0400 (EDT)

On Wed, 22 Jul 2009, 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.

The above is a good statement about your intent with regard to patent 
claims on draft-ietf-tls-extractor.

>   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,
> 
>   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 don't think this is what is meant by "relates". If lower protocol
layers "related" to the above cipher suites, then IP (RFC791) and TCP
(RFC793) also "relate" in the same way, and you did not list those
drafts.

>    V Disclosure of Patent Information (i.e., patents or patent
>      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.

It is good to know that this is your interpretation; that you mean
that there are patent claims only on 
  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

These documents (only these documents) should be listed in Section IV.
 
If you read the instructions for Section V.C, it is plain that you are
to identify "sections of the Internet-Draft or RFC that are alleged to
be so covered:", and you don't identify any sections.

If you have no patent claims on a draft, there should not be an IPR
disclosure on that document, except perhaps to make clear (via the
additional notes in Section V) that you have no patent claims on a
document.

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

It appears that your interpretation of Section IV, V and Section V.C
cannot be correct by reading the text for those sections. You apparently
did not read the instructions carefully.  If one isn't going to read the
text there now, there is no point in adding more text.

> A link I think most will find particularly amusing.

I didn't find the link amusing. I rather expected that you had found a
dead link or something, but that isn't the case. 

The link you cite provides contact information and directs one to the
disclosure template, which you filled out.  On that template, Section
V.C contains the same instructions as appear on the Disclosure.

====================== 
====================== 

Your interpretation of Section V.C cannot be correct by reading the text
for section V.C on the template. One wonders if you took the proper time
and solemnity to prepare the Certicom disclosures.

But I guess we have the information we need, now. Thanks. I hope you
quickly update the IPR disclosure to comply with the instructions for
each section and the actual facts Certicom is supposed to convey for
those sections.  Given the confusion so far, I think you will need to
add a comment for each document previously incorrectly listed in Section
IV for which there are no patent claims, clearly stating the fact of no
patent encumbrance on those specific documents.  Once that is done, and
it is clear there are no patent encumbrances on the extractor draft, I
will be happy to reconsider my objection to the extractor draft.

		--Dean

---

From: Todd Glassey <[email-masked]>
Date: Thu, 23 Jul 2009 10:37:07 -0700

>> intention to indicate any such claims.
Matthew -
I dont want to know your intentions were when you filed it but what I do 
want to know is what Certicom's commitment's are and in writing - and 
here is the key thing - it has to formally come from someone legally 
empowered by the Corporation to do so.

Otherwise (no offense meant) what you personally want is irrelevant 
unless you are specifically the inventor and are reclaiming that IP...
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.392 / Virus Database: 270.13.25/2256 - Release Date: 07/23/09 06:02:00
>
>

---

From: Richard Stallman <[email-masked]>
Date: Thu, 23 Jul 2009 21:37:54 -0400

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.

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 23 Jul 2009 20:19:09 -0700

Richard and all,

  I agree largely.  Very little software warrents patenting.  Protection
of any authors software can much better and easily be done in other
ways.  Open source is not the total answer either as some types of
software in open source format would be ill advised.

Regards,

---

From: Richard Stallman <[email-masked]>
Date: Sat, 25 Jul 2009 00:55:19 -0400

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

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 25 Jul 2009 01:36:39 -0700

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: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 27 Jul 2009 17:39:23 -0700

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
>
> 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
>
> freedom to write and run certain kinds of software.  This is why we must
> abolish software patents.
>
> 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-honest mailing list
> [email-masked]
> http://lists.iadl.org/mailman/listinfo/ietf-honest

Regards,

---

From: Richard Stallman <[email-masked]>
Date: Tue, 28 Jul 2009 00:36:44 -0400

actually reduce the number of law suits out there.

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.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Jul 2009 09:22:24 +0200

David Morris <[email-masked]> writes:

> On Thu, 23 Jul 2009, Richard Stallman wrote:
>
>
> 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.

I agree, but I don't see anyone making an argument against that.  What
the question here is about is to classify this (already accessible)
documentation as an Internet Standard.  That sends a message that the
document is what the IETF recommends to use.  There is a significant
difference.

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

I believe the problem with this patent disclosure is that it isn't clear
what is claimed.  People are trying to resolve the issue, and this is
what the IETF process is about: we need to evaluate things on a
document-by-document basis.

Fear of patent claims have been successfully used as arguments to
publish documents as Informational instead of Proposed Standard before,
compare, e.g., RFC 5054 on TLS-SRP.

Thanks,
Simon

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 27 Jul 2009 12:51:05 -0400

- Wes 

-----Original Message-----

    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.

---

From: David Morris <[email-masked]>
Date: Mon, 27 Jul 2009 18:34:54 -0700 (PDT)

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.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 28 Jul 2009 13:57:57 -0400 (EDT)

On Mon, 27 Jul 2009, Wes Beebee (wbeebee) wrote:

> that no one ends up suing anyone else.  

What you say is true, and is basically why the LPF accepts mutually
defensive patents.  http://www.progfree.org/Patents/mutual-def.html Of
course, they key is the nonagression policy and the universal free
license.

But the above just recognizes the realities imposed by the laws of an
unfair patent system. Patents (mutally defensive) are better than no
patents whatsoever. While publication and prior are helpful, the law
gives (unfairly we argue) benefits to patent holders including mutually
defensive patent holders.

So, there is still a reason to change the law on patents. These mutually
defensive patents are still expensive, and must still be defended to
some extent: e.g. against an agressive patent holder of an overlapping
patent who seeks to enjoin against the mut-def patent application.

I think there are two reasons for the IETF to consider patented
technology:

First, I think the IETF is made up of a majority of people who are
anti-patent in their views. But industry players who are agressively
pro-patent (as we have seen) also participate, and it seems (strangely)
control the leadership.  Despite the actions of the IESG silencing
critics, the IETF does not actually have a right to deny participation
to those players who merely disagree with the majority. To do so is a
violation of the Hobbs Act on democratic participation, and a violation
of anti-trust laws.  Morally, it would just be wrong to deny
participation to the opposition.  We have to respect the rights of the
opposition to participate, even when they don't respect our right to
participate.

Second, Truly novel, superior patents are very, very rare. The example I
hold up is the (hypothetical) patenting of the fast fourier transform
(FFT). The FFT is so superior and so novel in signal processing, that if
it were patented people doing signal processing would have no choice but
to standardize it and pay whatever fees were demanded.  If something
like that happened, it would be a very, very sad day. But that
possibility it is really just another reason to change the law on
patents.  But fortunately, I haven't seen that level of novelty and
superiority in any patented technology so far proposed to the IETF.  
Most patent technology I have seen so far proposed to the IETF is either
not very novel and/or not very superior and, most significant to a
standarization decision, is easily replaced by non-patented technology.

In the case the IETF approves a patented standard, I would hope that the
IETF only does so for a mutually defensive patent, or only in the case
were something is so novel and so superior as to be like the FFT to
signals and systems analysis. Anything less seems like a very poor
choice.

So the IETF /can/ make a decision to approve a patented technology. But
of course, mere procedural ability to approve a patented technology is
no reason to approve a non-free patented technology that is easily
replaced by non-patented technology. We should make intelligent and
informed decisions.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 28 Jul 2009 14:04:34 -0400 (EDT)

> used it in commerce before another and can prove such that is

Not under a first-to-file regime, which the US is changing to, and the
rest of the world uses now. First-to-file will still deny patents on
established prior art and non-novel inventions, but places limits. I've
heard variously that any prior-art less than a year prior will be
excluded from invalidating a first-to-file patent.

One really does have to race to the patent office. And of course, the
big companies with army of patent lawyers and camps outside the patent
office will win that race most of the time.

		--Dean

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 28 Jul 2009 18:59:07 -0700

Dean and all,

  No offense Dean but I think you miss read or miss understood my
previous response.  I wasn't suggesting of talking about a prior
filing of a patent or even a patent on a similar product or service,
but the USE of a similar, even confusingly similar product or process
that had or has prior USE AND was never filed for patent protection.
The LAN ham act has yet to be amended as you suggest BTW, although
there has been legislation that would amend the Lanham Act as you
suggest, but it has little support currently.

Regards,

---

From: Dean Anderson <[email-masked]>
Date: Wed, 29 Jul 2009 14:19:43 -0400 (EDT)

I think I understood what you are saying. Under first-to-invent, such
use establishes priority. Under first-to-file, it doesn't---or rather,
its limited in how it does.

As I understand it, under the first-to-file changes (which we are
obligated to make under GATT treaty), First use, prior art, and actual
invention, don't matter as much as they did previously. Under the new
system, inventors (those who can prove they are inventors as before) are
grandfathered under first-to-file. The grandfather law was passed some
years ago--I can't recall offhand what it was called. Inventors (who
could have previously invalidated the other patent and/or obtained their
own patent under the old first-to-invent regime), are now granted the
privilege to use, but not sell or license, the technology they invented,
but that someone else filed a patent on first.

I don't believe the Lanham act stands in the way of a change from
first-to-invent to first-to-file. Already there is a range of activity
that falls somewhere between misuse and anti-trust violation. But its
probably worth more investigation.  I think in principle, anti-trust is
a argument against having patents, but at present, anti-trust law is not
usually sufficient to overturn patents.

Use during patent-pending period is ok, but would be prevented after the
patnent is approved.  I think the only thing that prior commercial use
is good for is establishing proof of prior art and prior invention, and
these factors are going to be limited in the near future.

		--Dean

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 29 Jul 2009 11:41:58 -0700

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,

-----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: Paul Hoffman <[email-masked]>
Date: Wed, 29 Jul 2009 21:34:09 +0200

>   <draft-ietf-tls-extractor-06.txt> as a Proposed Standard

Given the recent discussion, I continue to support the publication of this document as a Standards Track RFC.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 29 Jul 2009 19:56:11 -0700

Larry and all,

  I agree with your conclusion here Larry!  Well done!  But what
will determine what precisely will be that standard, if any, and
if not standard is determined as a result or otherwise, how will
full interoperability be accomplished?

Regards,