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

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

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:
> 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:
>
>> 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
>>
>> _______________________________________________
>> 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
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

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

Nikos Mavrogiannopoulos wrote:
> 
> I'd propose to add this text to the standard:
> This protocol MUST NOT be used with RFC4492, RFC5289 and
> 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: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 21 Jul 2009 17:48:53 +0300

That way the certicom's patents are not applicable.

---

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: Eric Rescorla <[email-masked]>
Date: Wed, 22 Jul 2009 06:51:36 -0700

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

[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
> 		--Dean
> 
> On Wed, 22 Jul 2009, Joseph Salowey (jsalowey) wrote:
> 
> > 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: Tue, 21 Jul 2009 14:50:28 -0500

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

> draft-ietf-tls-extractor should proceed even without such a statement.

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: Florian Weimer <[email-masked]>
Date: Wed, 22 Jul 2009 09:59:38 +0000

* Paul Hoffman:

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

> 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

---

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.

Dean Anderson wrote:

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

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

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.

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

---

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

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

---

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

David Morris <[email-masked]> writes:

> behavior is ALWAYS better than no public documentation for commonly
> used protocols. As a person with frequent exposure to the operational

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.

> 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: 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: "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: Dave Cridland <[email-masked]>
Date: Thu, 30 Jul 2009 09:08:17 +0100

> basic policy that should be adopted by IETF.

I'm not in favour of software patents, and whilst I don't do much  
open-source or free software these days, I'd certainly at least nod  
pensively at the suggestions that open-source implementations both  
help specification development and act as a good indicator of the  
interest in a proposal and the general health of the protocols.

I am also not in favour of burying my head in the sand. All SDOs -  
the IETF included most especially, as having set the standard to live  
up to - should primarily exist to document what *is*, not what one  
might want to be. It's often commented that the IETF, whilst good at  
refining designs, rarely produces new protocols successfully, and  
it's certainly not alone there.

It's been phrased in terms of "running code" before, by another Dave  
- I like to call it "documenting reality", or "not living in cloud  
cuckoo land".

The case where a patent is known from the outset, or even is known  
very early on, is often a case where the IETF *does* route around the  
damage. The exceptions tend to be where the specification either  
describes the only, or the only sensible, method for doing something.

Other cases, though, include cases much closer to the well-known  
UNISYS GIF patents, where a well-deployed specification turns out to  
have a patent applicable to it - or at least a patent potentially  
applicable to it.

In either case, the IETF essentially has two choices:

1) It chooses to throw away the core principle of "documenting  
reality". This is damaging in itself, because - just like producing  
avoidable specifications which have known patents - it risks having  
the IETF produce irrelevant standards, and thus becoming irrelevant  
itself.

In the case of PNG, it's my understanding that PNG only overtook GIF  
on the web due to technical superiority used by better displays,  
rather than patent encumberances - certainly when the patents were in  
effect, I saw lots of rhetoric, but lots of GIFs, too.

2) It documents what is, including that it's patented, and those  
participants who care about unemcumbered standards attempt to have  
the market route around the damage instead.

This strategy has two advantages - firstly, it works whether the  
patent is known from the outset or not, giving us a consistent  
policy. Secondly, it means that we can get on nicely with the  
pro-patent crowd, document the encumbered stuff, and then have the  
patents documented too - it could be argued as having the effect of  
sonar on submarine patents.

So, in summary, by all means argue against patents - I'm right with  
you, and so are a lot of the other participants here. But argue  
somewhere else - the debate isn't appropriate here, and many here see  
your rhetoric with pragmaticism.

Here, you need a working counter-proposal, that the market can then  
use to route around the damage. There's a lot of open-source projects  
that respond to many suggestions with "please provide a patch" - I  
encourage those interested to do the equivalent here.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

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,