Subject: [TLS] Proto write-up for TLS exporter

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 11 May 2009 22:58:40 -0700

(1.a) Who is the Document Shepherd for this document? Has the 
          Document Shepherd personally reviewed this version of the 
          document and, in particular, does he or she believe this 
          version is ready for forwarding to the IESG for publication? 

I, Joe Salowey, co-chair of the TLS working group, am the Document
shepherd for this document.  I have reviewed the document and I believe
it is ready for forwarding to the IESG for publication.  

    (1.b) Has the document had adequate review both from key WG members 
          and from key non-WG members? Does the Document Shepherd have 
          any concerns about the depth or breadth of the reviews that 
          have been performed? 

The document has been reviewed by key working group members that
understand TLS.  The document has also been reviewed by members of the
cryptographic community that are experts in key derivation.  

    (1.c) Does the Document Shepherd have concerns that the document 
          needs more review from a particular or broader perspective, 
          e.g., security, operational complexity, someone familiar with 
          AAA, internationalization or XML? 

The document deals with cryptography and has had cryptographic review.  

    (1.d) Does the Document Shepherd have any specific concerns or 
          issues with this document that the Responsible Area Director 
          and/or the IESG should be aware of? For example, perhaps he 
          or she is uncomfortable with certain parts of the document, or

          has concerns whether there really is a need for it. In any 
          event, if the WG has discussed those issues and has indicated 
          that it still wishes to advance the document, detail those 
          concerns here. Has an IPR disclosure related to this document 
          been filed? If so, please include a reference to the 
          disclosure and summarize the WG discussion and conclusion on 
          this issue. 

The document shepherd has no concerns with the document.  There is an
IPR disclosure that lists this document:
https://datatracker.ietf.org/ipr/1004/.  The contents of this disclosure
where originally posted to the list on June 30, 2008
(http://www.ietf.org/mail-archive/web/tls/current/msg02770.html).   The
IETF IPR disclosure reference was recently posted to the TLS list as
well.  There has been little discussion on this in the working group.
The general sentiment is that the IPR is applicable to cases where ECC
certificates are used. 

    (1.e) How solid is the WG consensus behind this document? Does it 
          represent the strong concurrence of a few individuals, with 
          others being silent, or does the WG as a whole understand and 
          agree with it? 

The consensus behind this document is strong with decent support and
participation from the working group. 

    (1.f) Has anyone threatened an appeal or otherwise indicated extreme

          discontent? If so, please summarise the areas of conflict in 
          separate email messages to the Responsible Area Director. (It 
          should be in a separate email because this questionnaire is 
          entered into the ID Tracker.) 

No. 

    (1.g) Has the Document Shepherd personally verified that the 
          document satisfies all ID nits? (See 
          http://www.ietf.org/ID-Checklist.html and 
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
          not enough; this check needs to be thorough. Has the document 
          met all formal review criteria it needs to, such as the MIB 
          Doctor, media type and URI type reviews? 

There are a few nits with respect to references in the document.  There
is also one instance of "MUST not" that should be replaced by "MUST
NOT".  

    (1.h) Has the document split its references into normative and 
          informative? Are there normative references to documents that 
          are not ready for advancement or are otherwise in an unclear 
          state? If such normative references exist, what is the 
          strategy for their completion? Are there normative references 
          that are downward references, as described in [RFC3967]? If 
          so, list these downward references to support the Area 
          Director in the Last Call procedure for them [RFC3967]. 

The Document has split references.  In the current version some of the
references are out of date or missing.  A informative reference to RFC
5216 should be added in place of 2716.  The reference to RFC 5281 should
be informative.  The reference to the DTLS-SRTP draft should be
rectified in the text.  

    (1.i) Has the Document Shepherd verified that the document IANA 
          consideration section exists and is consistent with the body 
          of the document? If the document specifies protocol 
          extensions, are reservations requested in appropriate IANA 
          registries? Are the IANA registries clearly identified? If 
          the document creates a new registry, does it define the 
          proposed initial contents of the registry and an allocation 
          procedure for future registrations? Does it suggest a 
          reasonable name for the new registry? See [RFC5226]. If the 
          document describes an Expert Review process has Shepherd 
          conferred with the Responsible Area Director so that the IESG 
          can appoint the needed Expert during the IESG Evaluation? 

Yes

    (1.j) Has the Document Shepherd verified that sections of the 
          document that are written in a formal language, such as XML 
          code, BNF rules, MIB definitions, etc., validate correctly in 
          an automated checker? 

Yes

    (1.k) The IESG approval announcement includes a Document 
          Announcement Write-Up. Please provide such a Document 
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval 
          announcement contains the following sections: 

          Technical Summary 

A number of protocols wish to leverage Transport Layer Security (TLS) to
perform key establishment but then use some of the keying material for
their own purposes.  This document describes a general mechanism for
allowing that.

          Working Group Summary 

There was significant consensus in the working group supporting this
document.  The largest controversy was over the name.      

          Document Quality 

The approach is planned for use in several protocols. The document has
been reviewed by cryptographers who are experts in the area of key
derivation.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 12 May 2009 17:59:09 +0200

"Joseph Salowey (jsalowey)" <[email-masked]> writes:

> (http://www.ietf.org/mail-archive/web/tls/current/msg02770.html).

That post does not relate to the #1004 patent disclosure.  The post
refers to the January 2006 license, which did not reference TLS
exporter.  The #1004 patent disclosure refers to the October 2008
license.

> The IETF IPR disclosure reference was recently posted to the TLS list
> as well.  There has been little discussion on this in the working
> group.

Possibly because it was posted yesterday.

> The general sentiment is that the IPR is applicable to cases where ECC

Can you provide a reference for this?  Who has made that interpretation?

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 May 2009 09:37:25 -0700

First off, the write-up doesn't say which document it is for. I assume that it is for draft-ietf-tls-extractor-05.txt.

At 5:59 PM +0200 5/12/09, Simon Josefsson wrote:
>exporter. 

Simon is correct.

>The #1004 patent disclosure refers to the October 2008
>license.

Yep.

>Can you provide a reference for this?  Who has made that interpretation?

Yes, please. I am not aware of any even vague consensus on what IPR #1004 means or applies to.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 12 May 2009 10:28:40 -0700

You're both absolutely right, when I looked at the PDF file on the
website I didn't connect that it was from October (I wonder if there was
another one previous that was supplanted by the October one).   Also,
the sentiment I related was from offline discussions and does not
represent working group consensus.  I'll update the write-up to include
the document title and the revised IPR discussion section below.   I'll
also hold off on forwarding to the IESG for a few days in case
discussion develops.  

Thanks for reading the PROTO write-up, its better to catch this now:

The document shepherd has no concerns with the document.  There is an
IPR disclosure that lists this document:
https://datatracker.ietf.org/ipr/1004/.  Although the IETF IPR
disclosure was posted in October, a reference was only recently posted
to the TLS list.  So far, there has been little discussion on this in
the working group.  Discussions outside the working group between the
chairs and others seem to indicate that the IPR is applicable to cases
where ECC certificates are used. 

Thanks,

Joe

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]] 
> Sent: Tuesday, May 12, 2009 9:37 AM
> To: Simon Josefsson; Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: Re: [TLS] Proto write-up for TLS exporter
> 
> First off, the write-up doesn't say which document it is for. 
> I assume that it is for draft-ietf-tls-extractor-05.txt.
> 
> 
> >The #1004 patent disclosure refers to the October 2008 license.
> 
> Yep.
> 
> > > The general sentiment is that the IPR is applicable to 
> cases where 
> > > ECC
> >> certificates are used.
> >

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 May 2009 19:48:11 +0200 (MEST)

> exporter.  The #1004 patent disclosure refers to the October 2008

I'm confused.  TLS exporters has nothing to do with ECC crypto
or X.509 certificates.  It is about a PRF and a shared secret
and random challenges between the TLS communication peers.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 May 2009 13:34:02 +0200

> and random challenges between the TLS communication peers.

That is right, but the #1004 patent disclosure claims to cover
tls-extractor.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 May 2009 13:58:54 +0200

I don't support publishing tls-extractor on the standards track as long
as there are unclear patent threat against it and no acceptable free
software compatible patent license is available.

I haven't seen anyone offer a credible analysis that the patent claims
would not taint an implementation of the document.  If someone presents
analysis, that would influence my opinion.

Putting this document on the standards track suggests that other IETF
documents should reference it on extracting keying material from TLS.
That seems like a poor recommendation to make broadly, because every
protocol that would make use of tls-extractor would then have the
uncertainty of being tainted by the Certicom patent claims.

I believe the wider Internet community will be better off by not
publishing the document as an RFC at all if the patent situation does
not improve.  We should not encourage patented technology for running
the global Internet.

The patent disclosure was posted to this list only a few days ago.  It
has not been mentioned in earlier discussions of the draft or during
WGLC's as far as I recall.  I believe a few days is a too short time to
be able to establish consensus.  Referring to external discussions in
the proto-writeup is not acceptable, it explicitly requests reference to
WG discussions about the patent disclaimer.

/Simon

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 May 2009 08:12:44 -0700

At Tue, 12 May 2009 17:59:09 +0200,
> Can you provide a reference for this?  Who has made that interpretation?

I don't know about consensus, but that's my interpretation. I made it
based on the PDF file linked from the #1004 disclosure which seems to
me to pretty clearly state that extractor (and pretty much every other
TLS document) apply when used with ECC:

IETF TLS: 
"The Transport Layer Security (TLS) Protocol  Version 1.1," RFC 4346 or "The Transport Layer 
Security (TLS) Protocol  Version 1.2," RFC 5246, or "Datagram Transport Layer Security (DTLS)  
Version 1.2," draftietftlsrfc4347bis00.txt, or "Transport Layer Security (TLS) Extensions", 
RFC 4366, or  "Datagram Transport Layer Security (DTLS)  Version 1.0", RFC 4347, or   
"Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Realtime 
Transport Protocol (SRTP)", draftietfavtdtlssrtp05.txt or "Keying Material Extractors for 
Transport Layer Security (TLS)", draftietftlsextractor02.txt  when used with either: 
        
            A. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer 
                Security(TLS)" RFC 4492, May 2006; or, 
            B. "TLS Elliptic Curve Cipher Suites with SHA256/384 and AES Galois Counter 
                Mode," RFC 5289, or 
            C. "Suite B Cipher Suites for TLS," draftrescorlatlssuiteb07.txt; 

Do you have some reason to believe that extractors itself is encumbered absent
use of ECC?

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 May 2009 08:21:59 -0700

>software compatible patent license is available.

This is absurd and obstructionist. You are saying that if anyone publishes an IPR statement about a work in progress, they can stop that document from becoming a standard.

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 May 2009 18:49:01 +0200 (MEST)

> That is right, but the #1004 patent disclosure claims to cover

Could someone please ask Certicom to remove TLS-extractors from
their IPR claim / IPR disclosure?

To me, this claim sound ridiculous (assuming their patent claims
are purely about patents around EC crypto).

Can Bayer raise patent claims for a human being who has been
treated with CiproBay?

Or can Monsanto raise a patent claim for a human being who processed
(i.e. ate and digested) roundup-ready corn?

If such claims are really possible in the US, then you do have
a problem with your patent system over there.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 May 2009 10:01:16 -0700

>their IPR claim / IPR disclosure?

This might best be done by someone who works for a large vendor who has a business relationship with Certicom or their parent, RIM (hint, hint).

>are purely about patents around EC crypto).

Why is what you think (or what I think) about their IPR relevant to the write-up? Joe is reporting that there is an IPR statement in which the draft is mentioned. That is a factual statement, even if it is unfortunate.

<rest of IPRsuxox discussion elided because it is inappropriate here>

--Paul Hoffman, Director
--VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 May 2009 19:27:42 +0200

> Do you have some reason to believe that extractors itself is encumbered absent

Some of the patents quoted by Certicom in that PDF do not appear to be
specific to ECC.  There is no analysis that they don't apply to
tls-extractor.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 May 2009 19:28:34 +0200

Paul Hoffman <[email-masked]> writes:

> This is absurd and obstructionist. You are saying that if anyone
> publishes an IPR statement about a work in progress, they can stop
> that document from becoming a standard.

I'm absolutely not saying that.  Please re-read what I wrote.

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 May 2009 10:59:11 -0700

>I'm absolutely not saying that.  Please re-read what I wrote.

You are and I did, carefully.

You know full well that any IPR statement in the IETF can be considered an "unclear patent threat" by many people. Further, you know that the phrase "no acceptable free software compatible patent license" is unclear to many IETF participants, much less to many patent owners.

Given your two restrictions, I believe my statement is true.

--Paul Hoffman, Director
--VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 May 2009 20:43:28 +0200

Paul Hoffman <[email-masked]> writes:

> You know full well that any IPR statement in the IETF can be
> considered an "unclear patent threat" by many people. Further, you
> know that the phrase "no acceptable free software compatible patent
> license" is unclear to many IETF participants, much less to many
> patent owners.
>

Those two restrictions are something you invented, they are not in what
I wrote and they are not what I intended.  Conveniently, the
restrictions you carefully chose made your statement true.  The patent
threat and patent license is unclear _to me_ and _right now_.  That is
sufficient for me to not support publishing the document at this point.

WG's should discuss patent disclaimers and decide whether to live with
the problem or not.  That discussion had not taken place for
tls-extractor before the proto-writeup was posted.  I'm hoping the
discussion will provide more grounds to base the decision on.

The IETF needs to carefully weight patent threats when considering
standardization.  I believe implying that such considerations are
obstructions hurt the credibility of the IETF as a standardization body
for the Internet.

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 May 2009 12:54:15 -0700

At 8:43 PM +0200 5/13/09, Simon Josefsson wrote:
>I wrote

Wait, what?!? Are you saying that I lied in the text at the top of this message, and that the official archive of your message at <http://www.ietf.org/mail-archive/web/tls/current/msg03476.html> is also lying?

>and they are not what I intended.

Well, that is certainly believable.

> Conveniently, the

That's not what you said.

Further, it is still absurd and obstructionist to say that a document cannot be published on standards track as long as someone thinks it has one or more "unclear patent threat against it". Anyone can write an IPR statement that is unclear to someone.

>the problem or not.

Sure. However, such discussions should not hinge on whether anyone finds the threat unclear. Nor should they hinge on how different people interpret acceptable free software compatible patent license".

>That discussion had not taken place for

Some people would find that starting this with un-meetable demands is not conducive to a discussion.

>standardization.

No, we don't. You have been repeatedly on the losing side of this discussion in the IPR WG. Bringing it up in every WG you follow does not change that fact.

>I believe implying that such considerations are

In whose eyes will the IETF's credibility be enhanced by re-opening this discussion every time you want it to?

--Paul Hoffman, Director
--VPN Consortium

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 14 May 2009 00:34:45 +0300

> Further, it is still absurd and obstructionist to say that a document cannot be published on standards track as long as someone thinks it has one or more "unclear patent threat against it". Anyone…

As far as I remember this was the consensus of this WG for the TLS-SRP
now informational RFC. Once someone submitted an unclear patent thread
against it, the WG decided not to move forward as a standards track,
rather as informational.

http://www.ietf.org/mail-archive/web/tls/current/msg01215.html

> Sure. However, such discussions should not hinge on whether anyone finds the threat unclear. Nor should they hinge on how different people interpret acceptable free software compatible patent licen…

I do not understand the comments about. If it is some rant on free
software I do not bother even discussing them.

> No, we don't. You have been repeatedly on the losing side of this discussion in the IPR WG. Bringing it up in every WG you follow does not change that fact.

Nevertheless I see no reason not to bring it up if he thinks it the
problem is there. .

regards,
Nikos

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 May 2009 15:53:18 -0700

>against it, the WG decided not to move forward as a standards track,

On review of the archives, I disagree that the choice to go for Informational was because the patent status was unclear. It seemed that many people thought the status was clear and negative for standardization. This is, of course, subjective on my part.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 May 2009 16:00:17 -0700

At Wed, 13 May 2009 19:27:42 +0200,
> specific to ECC.  There is no analysis that they don't apply to

Again, the disclosure seems pretty clear to me. Namely,
it states that the named documents apply "when used with...
<three ECC-related documents>"

So, again, I ask, "Do you have some reason to believe that extractors
itself is encumbered absent use of ECC?"

-Ekr

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 14 May 2009 10:44:28 +0200

Paul, allow me to explain what I originally intended and how you
interpreted it:

My position: I don't support tls-extractor on standards track if I
believe there are unclear patent threats and/or no acceptable free
software license.

Your interpretation: Simon doesn't support tls-extractor on standards
track as long as there is _someone_ that believes there are unclear
patent threats and/or no acceptable free software licenses.

I stand by my position.  Your interpretation of what I said is not what
I intended and I completely disagree with that interpretation.  Don't
put those words in my mouth.  I agree that your interpretation is
counter-productive.  English isn't my native tongue, but even after
re-reading what I wrote I don't see it saying what you believe it said.

> Further, it is still absurd and obstructionist to say that a document
> cannot be published on standards track as long as someone thinks it
> has one or more "unclear patent threat against it". Anyone can write
> an IPR statement that is unclear to someone.

Sure, and that act should rightly delay publication until it has been
discussed.  I believe the patent disclaimer needs to be considered
before publication.  That does not mean it should stop the document.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 14 May 2009 11:17:02 +0200

> itself is encumbered absent use of ECC?"

I believe the PDF is a reason, at least without more information.  My
reasoning is as follows:

The patent disclaimer filed with the IETF lists tls-extractor as one
document that Certicom believes is covered by their patents.

The PDF only covers when ECC is used.

The PDF does not assert anything about non-ECC purposes.

This allows Certicom to claim that the tls-extractor document is covered
by their patents for non-ECC uses in the future.  That claim would not
be inconsistent with the information filed with the IETF so far.  That
is the loophole I'm concerned with.

My inclination is to be conservative about assuming the intentions of
patent holders without at least public statement to the contrary.

/Simon

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 May 2009 07:04:37 -0700

At Thu, 14 May 2009 11:17:02 +0200,
> is the loophole I'm concerned with.

While, this is of course true, it's also possible that some other
entity which doesn't participate in IETF at all has patents that apply
to extractor. That wouldn't be inconsistent with the information filed
with the IETF either.

Either you think that Certicom has a BCP 79 obligation to accurately
disclose their patents or they don't. If you do, I think it's
reasonable to conclude that when they say "our patents may cover
X" that they don't believe their patents cover !X. If you don't,
then we could equally well conclude that their patents may
cover drafts they don't even mention. 

-Ekr

---

From: Badra <[email-masked]>
Date: Thu, 14 May 2009 16:10:01 +0200

> cover drafts they don't even mention.

May it be possible for the draft's authors to review the related Certicom's
patents and conclude whatever they are or aren't related to the document in
question?

Best regards,
Badra

---

From: "Whyte, William" <[email-masked]>
Date: Thu, 14 May 2009 10:15:54 -0400

> May it be possible for the draft's authors to review the
> related Certicom's patents and conclude whatever they are
> or aren't related to the document in question?

Surely it'd be more efficient to ask Certicom for a revised
IPR making it clear whether or not they consider their 
patents to cover the draft in the absence of ECC.

William

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 May 2009 07:21:01 -0700

>believe there are unclear patent threats and/or no acceptable free

Ah. That is good to hear. It certainly was not clear from your original message.

>patent threats and/or no acceptable free software licenses.

Yes, that is how I (and others offline) interpreted it. Very glad to hear we were wrong.

>re-reading what I wrote I don't see it saying what you believe it said.

We can simply agree to disagree on that last part. As for your English: I have absolutely no criticisms of it. I always appreciate people who use English as a second language, given that I have no second language. I also know that I am quite lucky to have English as my first language, and to be a professional writer in it.

>before publication.  That does not mean it should stop the document.

That works for me.

--Paul Hoffman, Director
--VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 14 May 2009 16:47:38 +0200

> to extractor. That wouldn't be inconsistent with the information filed

Agreed.

> disclose their patents or they don't.

Companies do not have obligations per BCP 79, individuals do.

> If you do, I think it's reasonable to conclude that when they say "our
> patents may cover X" that they don't believe their patents cover
> !X.

I don't believe that is relevant -- in this case, Certicom has filed a
claim that they have patents that covers the tls-extractor document.
Full stop.

The additional information provided with the patent disclosure contains
advertisement and a patent license for use with ECC.  That doesn't imply
anything for non-ECC uses.

> If you don't, then we could equally well conclude that their patents
> may cover drafts they don't even mention.

That does not follow, but there is nothing in BCP 79 to prevent that
situation from happening.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 May 2009 10:48:23 -0500

> patents and conclude whatever they are or aren't related to the document in

Absolutely not.  A document author should _never_ have to do that unless
they are the owners of (or work for the owners of) the relevant patents.
Nor, to be clear, should the authors be required to produce such a
review (e.g., done by their lawyers).

If the IETF were ever to require me to do such analysis, in order to
prorgress an I-D that I'm an author of, when I'm not the IPR owner or an
agent thereof, then I'd simply refuse to do so and let the I-D expire
without further ado if need be.  I'm quite certain that my or my
employer's lawyers would insist on that very course of action.
Moreover, I'd stop participating in the IETF altogether, and I'm sure
many others would too.

It's not fair even to ask the authors to do such a review if they feel
like it.  It would probably be a dangerous expectation to set, that
authors should "volunteer" to do such reviews.  Moreover, such reviews
would do everyone else exactly no good.  Just because my or my lawyer's
opinion is that some IPR does not cover a given document cannot mean
that the IPR owner won't think otherwise and sue you if they think you
infringe on their IPR.

Simon is being unreasonable by acting as though assertions NOT made are
nonetheless in force.  We're not mind readers and the law does not and,
indeed, _must_ not expect us to so be (no, I am not a lawyer).  We can
and should (nay, must) only make decisions based on IPR claims that are
asserted, not on claims that are not asserted (again, IANAL, but you
knew that).

Simon should seek legal advice on that point, and hopefully remove his
objection (or perhaps the TLS WG chairs and/or IESG can just declare
consensus nonetheless and let Simon appeal if he likes).

Cheers,

Nico
--

---

From: Badra <[email-masked]>
Date: Thu, 14 May 2009 18:20:12 +0200

> that the IPR owner won't think otherwise and sue you if they think you

Well I am not asking the authors to do a survey on existing patents, BUT on
identified ones, which are in our case Certicom's Patents.

If a patent is proposed to be related to an ID, it is for the authors (not
the owners) benefits to do if they want to publish their document as ST
since the owner may prefer to hide this info or to don't make a disclosure
at all.

In ID, we usually found (I am not sure if this is still applicable)

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.
The above text doesn't make any difference between the owner and the author.
So if the authors is not the owner, BUT are aware of any patents related to
that, they are requested to tell about that.

Badra

---

From: Martin Rex <[email-masked]>
Date: Thu, 14 May 2009 19:44:57 +0200 (MEST)

> review (e.g., done by their lawyers).

I agree with Nico.  If anyone at all should be asked to do a review
whether the Certicom patent claim covers tls-extractors by accident
or intentionally (independent of its validity), then this would
be the IPR holder, i.e. Certicom themselves.

IMHO the discussion is not very fruitful.

The PRF as described in TLS extractors is so totally similar to
the PRF used in TLS itself over many years that I don't see a
problem of going for the same track, i.e. standards track.

If it helps (and Certicom doesn't want to drop its claim),
how about adding a few words to the document describing the
situation?

Something like:

There is the following IPR disclosure ABC from Company XYZ which
claims to cover technology described in this document (TLS-extractors).
Since the technology has been and still is used in exactly the same
fashion in the base standard (TLS) for many years, the working group
made a straw poll whether it is ok to assume that adding this
technology to an existing implementation is not going to add
more risk to the IPR claim (that does apply to TLS as well).
The working group consensus was "........".

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 May 2009 15:31:45 -0500

> be the IPR holder, i.e. Certicom themselves.

The patent holder can't be forced to do that either, except by denying
them the imprimatur of the IETF standards process for their technologies
(assuming that they want that).  We can ask them though.

> IMHO the discussion is not very fruitful.

Indeed.  We should move on.  There are no claims on the extractor itself
as of right now, thus no need for further controversy.

> problem of going for the same track, i.e. standards track.

Some things are obvious.  This is one of them.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 May 2009 15:36:39 -0500

> identified ones, which are in our case Certicom's Patents.

You clearly missed the point.  My advice w.r.t. other people's patents
is worthless to anyone but my employer or myself, and since I'm not an
IPR lawyer my advice on such matters (beyond "go talk to your lawyers")
is utterly worthless.  Why would ask me, or anyone else, for it, then?

Would you really risk your business on my legal advice when we have no
business relationship at all?

Worse, forcing one to come up with such advice and publish it would be
detrimental to one's legal position should one get sued.  Which is why
any sensible authors should (would!) simply stop participating if your
suggestion were IETF policy, or even just WG policy.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 15 May 2009 00:11:13 +0200 (MEST)

> suggestion were IETF policy, or even just WG policy.

I also have a serious problem with asking document authors or
IETF participants to read specific patents and advise on their
applicability.

My employer has explicitly asked us software engineers to NOT read
any (software) patents at all (and has blocked some well-known
patent databases for that reason on our company web proxy).

IIRC the reason is the US approach to patents where
"willful infringement" results in extra punitive damages
(was it something like 3x).  If one is infringing on IPR,
it is cheaper when not knowing about the infringement
before being sued.

So all I know about the Certicom ECC patents is what has been
said by people from Certicom on IETF Meetings (somewhere around 97/98
in PKIX and TLS) or on IETF working group mailing lists, and
at most the IPR disclosures listed on the IETF Web Server.

And btw., I have serious problems reading patents anyway,
particularly those written in english (not my native language).
The few US patents I ever looked at were almost completely
incomprehensible to me (from a technical standpoint what
they actually describe).

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 16 May 2009 15:39:09 +0200

> asserted, not on claims that are not asserted (again, IANAL, but you

That is not factual, assertions have been made: #1004 claims Certicom
has patents that covers tls-extractor.  To what extent those patents
apply, and in what contexts, is more a legal question than a technical.

> consensus nonetheless and let Simon appeal if he likes).

I believe everyone considering implementing this would be prudent to get
legal advice on what the Certicom patents means for them.

/Simon

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 May 2009 02:14:27 -0400 (EDT)

Several messages inline:

On Thu, 14 May 2009, Nicolas Williams wrote:
> 
> Simon is being unreasonable by acting as though assertions NOT made
> are nonetheless in force.  We're not mind readers and the law does not
> and, indeed, _must_ not expect us to so be (no, I am not a lawyer).  
> We can and should (nay, must) only make decisions based on IPR claims
> that are asserted, not on claims that are not asserted (again, IANAL,
> but you knew that).

Actually, Simon is both right and reasonable. One doesn't need to be a
mind reader, nor does one need to be a lawyer, to read patents [nor to
read and obey any law]. The jury won't be made up of lawyers.  It is a
fallacy that only lawyers need to be concerned with legal matters.  
Lawyers have the special privilege to represent other people in Court,
sort of like commercial pilots have the special privilege to fly other
people for hire.

In this case, the 'unstated' assertions are in the patents themselves,
which the IPR Disclosures have disclosed.  The law expects you to use
due diligence to follow the references you've been given.  Infringing on
ignorance isn't excused--one still owes the money---and knowingly
infringing a patent can be prosecuted as a crime.  Lawyers have told me
that merely doing a /patent search/ can be evidence that you knew of a
patent--the lawyer was advising myself and other engineers against doing
patent searches. In this case, the IPR disclosure has informed us of the
patents, and so we can't plead ignorance. Inducing others to infringe is
also a special kind of patent offense.

Back to specifics: I've read a number of the Certicom patents, and they
are /very/ broad. I can't imagine much use of ECC that would not
infringe.  To be perfectly clear: I don't see that there is a credible
dispute for asserting non-infringement on ECC. The draft has disclosure;
the patent holder offers a (not really free) license. The patents
themselves are very broad, and there are a large number of them. I think
we have to conclude that unlicenced use of ECC will infringe.

> consensus nonetheless and let Simon appeal if he likes).

I'm not sure what your mean by 'declare consensus' here. Do you mean
that the IESG should state that the patents don't apply?

If so, I would point out that neither the Chairs nor the IESG can
honestly "declare"  consensus where there is no consensus. From RFC
2418:

   Consensus
   can be determined by a show of hands, humming, or any other means on
   which the WG agrees (by rough consensus, of course).  Note that 51%
   of the working group does not qualify as "rough consensus" and 99% is
   better than rough.  It is up to the Chair to determine if rough
   consensus has been reached.

There doesn't seem to be consensus on the draft as a whole so far.

On Wed, 13 May 2009, Paul Hoffman wrote:

> >I don't support publishing tls-extractor on the standards track as
> >long as there are unclear patent threat against it and no acceptable
> >free software compatible patent license is available.
>

I don't think that is what he is saying. He is saying that he doesn't
support the draft because of its patent licencing requirements. That is
a perfectly valid reason to oppose the draft. That's why RFC 3979
requires disclosures and requires working groups to discuss non-patented
alternatives.

On Wed, 13 May 2009, Paul Hoffman wrote:

> This might best be done by someone who works for a large vendor who
> has a business relationship with Certicom or their parent, RIM (hint,
> hint).

Removing the IPR claim has no effect. The only thing that can be done to
remove the objection of many is for Certicom to offer a free, universal
license to that technology.

> Why is what you think (or what I think) about their IPR relevant to
> the write-up? Joe is reporting that there is an IPR statement in which
> the draft is mentioned. That is a factual statement, even if it is
> unfortunate.

On Fri, 15 May 2009, Matthew Campagna wrote:

> In hopes of clarifying,
>
> 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.

Very few patent holders /don't/ want to foster broad adoption of their
technology.  Its the right of patent holders to prevent all use, but
broad adoption is frequently the goal of the patent holder, along with
the accompanying license fees, of course.  I do not dispute your goal of
broad adoption. I dispute that your license is really free, and I
dispute that we need to adopt ECC technology into TLS on a non-free
basis.

		--Dean

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 17 May 2009 23:51:08 -0700

At Mon, 18 May 2009 02:14:27 -0400 (EDT),
> dispute that we need to adopt ECC technology into TLS on a non-free

Nor is there any suggestion that we do so.

TLS Exporters are a generic technology that applies to any TLS 
cipher suite. There's no ECC in it at all. 

-Ekr

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 May 2009 05:07:47 -0400 (EDT)

I may have been unclear. Simon really has a firm grasp of the issues in
this case, see his message of 13 May 2009 (below)

The point is that we should figure out the IPR issue before we approve
this document.  We have a last minute disclosure which we don't
understand, yet.  As Simon notes, there is a lot not specific to ECC
that might be in those patents, even the ECC patent documents could have
patented something overlapped by the extractor draft. If there is really
nothing there, then we'll figure that out and advance the document.  
But if there is something there, we will want to know that.

Not knowing these answers, it seems prudent to wait.  (I rather feel
rushed by Paul Hoffman et al. I get the distinct feeling--like a used
car saleman trying to keep me from taking another look at the used car
they want to sell me.)  This tends to make me more hesitant.

Certicom could be helpful and state whether this draft infringes any of
their patents, and which.  Their offer to licence isn't an assurance of
no infringement; just the opposite: their offer implies that the draft
infringes something.  What?

I oppose the document at this time, until we have answers to the IPR
questions.

		--Dean

On Wed, 13 May 2009, Simon Josefsson wrote:

> > Do you have some reason to believe that extractors itself is
> > encumbered absent use of ECC?
>

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 May 2009 05:36:19 -0400 (EDT)

> business relationship at all?

Whether a document infringes a patent isn't a legal opinion; Its a
technical, factual opinion with legal consequences.  Its a technical
opinion that you are able to honestly answer. Of course, its just as
possible for one to dishonestly answer a technical question; but the
point is that its not your legal opinion that would have us concerned.

> suggestion were IETF policy, or even just WG policy.

Its only detrimental if its found to be dishonest in some way. 'Anything
you say can be used against you' is a warning not to lie; not an
inducement to withhold truthful statements.  But true statements usually
doesn't work against you, unless, for example, you say it infringes,
then you infringe anyway. In that case, the truth damns you.

This gives a decision-trust tree that allows trust to be placed in the
(non-patent-owning/employed) author when they say something /does/
infringe (because it increases their expenses), but not when the author
claims the patents don't infringe (because it reduces their expenses).  

But, of course, it is indeed much better if the patent owner says it
doesn't infringe. If the patent owner says that, and we rely on their
statement, then they might have 'unclean hands" for having deceived us
if they try to sue for infringement later.

		--Dean

---

From: <[email-masked]>
Date: Mon, 18 May 2009 12:42:06 +0200

> The working group consensus was "........".

No. See RFC 3979, Section 11.

Best regards,
Pasi

---

From: <[email-masked]>
Date: Mon, 18 May 2009 12:47:29 +0200

Badra wrote:

> If a patent is proposed to be related to an ID, it is for the
> authors (not the owners) benefits to do if they want to publish
> their document as ST since the owner may prefer to hide this info or
> to don't make a disclosure at all.
>
> The above text doesn't make any difference between the owner and the
> author. So if the authors is not the owner, BUT are aware of any
> patents related to that, they are requested to tell about that.

Note that "Section 6 of BCP 79" mentioned above *does* make a rather
big difference difference between the owner and the author (or
other contributor). 

Best regards,
Pasi

---

From: <[email-masked]>
Date: Mon, 18 May 2009 13:11:08 +0200

> document that Certicom believes is covered by their patents.

The IPR disclosure form (not the PDF) filed with the IETF says the
disclosure is "related to" a big list of IETF documents.  I think
there's a difference between saying "the disclosure is related to X"
and "the patents cover X", but your reading may of course be
different (and IANAL).

(The PDF certainly has statements effectively saying "Certicom believes
..something..  is covered by their patents", but the "..something.."
is more complex than just the list of RFCs/drafts.)

Best regards,
Pasi
(not wearing any hats)

---

From: <[email-masked]>
Date: Mon, 18 May 2009 13:13:43 +0200

Dean Anderson wrote:

> understand, yet.  

BTW, the disclosure was filed over half a year ago.

Best regards,
Pasi

---

From: <[email-masked]>
Date: Mon, 18 May 2009 13:24:51 +0200

> apply, and in what contexts, is more a legal question than a technical.

Well, the assertion that has been factually made is the following:

   At this time, Certicom believes its patents and patent applications
   listed in Schedule A contain claims which may be necessary and
   essential to implementations of the following protocols:

   IETF TLS:

   <...> "Keying Material Extractors for Transport Layer Security
   (TLS)", draft-ietf-tls-extractor-02.txt when used with either:

   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;

Your summary ("Certicom has patents that covers tls-extractor") seems
to take the opinion that the "when used with either: A or B or C" text 
is either not part of the assertion, or that this part doesn't matter.

My reading of the emails so far is that some others believe this
part of the assertion text *does* matter (and has influenced their
opinion about how to process the tls-extractor draft in IETF).
 
Best regards,
Pasi
<not wearing any hats>

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 May 2009 13:47:22 +0200

> and "the patents cover X", but your reading may of course be

I agree with you.

For reference, the page says 'IV. IETF Document or Other Contribution to
Which this IPR Disclosure Relates:'.  See
<https://datatracker.ietf.org/ipr/1004/>.

Fortunately, BCP79 is clear on what should be in the 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.  If the
   IETF Document is an Internet-Draft, it must be referenced by specific
   version number.

It seems as if the IETF web page, by using "relates", is partially to
blame for this confusion.  The intention (by my reading of BCP79 at
least) is not that all documents that are related should be listed, but
only those that are "actively affected".  There is certainly a
significant difference.

I think what I'd like to see here is

1) The IETF web page uses language that is consistent with BCP 79,

2) That Certicom updates the patent disclosure.

If the new patent disclosure no longer imply that Certicom believe they
have patents on tls-extractor, my concern would be resolved.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 May 2009 13:56:57 +0200

>        draft-rescorla-tls-suiteb-07.txt;

That is text from a PDF linked in 'Licensing information, comments,
notes, or URL for further information'.

> is either not part of the assertion, or that this part doesn't matter.

That is right, I don't consider the PDF as part of the BCP79-required
disclosure.  It is extra information beyond what is required by BCP79.
The PDF can certainly be useful in evaluating claims, but I believe the
text that's in the #1004 disclosure should carry more weight.  And the
tls-extractor document is mentioned as a covered technology for the BCP
79 patent disclosure.

> opinion about how to process the tls-extractor draft in IETF).

This seems to be the case.  I don't believe that view is consistent with
the requirements in BCP 79 on patent disclosures though.

/Simon

---

From: <[email-masked]>
Date: Mon, 18 May 2009 15:49:00 +0200

Simon Josefsson wrote:

> > Your summary ("Certicom has patents that covers tls-extractor")
> > seems to take the opinion that the "when used with either: A or B
> > or C" text is either not part of the assertion, or that this part
> > doesn't matter.
> 

Hmm.. it's quite common to *not* use the web form, but instead put the
disclosure information in a separate PDF or text file, and send that
by email (BCP79 doesn't require using the web form, AFAIK).

However, if you send the PDF/text/Word/whatever file by email, the
secretariat posts it on ietf.org. Having just a link to a file hosted
elsewhere is indeed unusual (and perhaps less than ideal for ensuring
the file stays available forever and is not modified).

If the PDF file linked in IPR disclosure #1004 was posted on ietf.org
(the same way as other IPR disclosures done as PDF files, such as 
https://datatracker.ietf.org/ipr/1040/), would that change
your opinion here?

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 May 2009 16:27:16 +0200

> by email (BCP79 doesn't require using the web form, AFAIK).

Sure, but everyone still have to follow BCP 79.

> https://datatracker.ietf.org/ipr/1040/), would that change

The important thing is the content of the disclosure, not its
presentation.

BCP 79 requires companies to disclose if they believe they have patents
on a document.  Certicom appears to have done that for tls-extractor,
judging from the #1004 page.

They provide no licensing or any information at all except for the
already known patent encumbered context of ECC.  If they were to publish
details for non-ECC, we would at least know how to evaluate the patent
claims on tls-extractor.  Right now we just have an patent claim with no
information beyond ECC.

If Certicom changes their patent disclosure to not claim they have
patents on tls-extractor, my concern would be addressed.  I'm hoping
this will happen.

If Certicom changes their disclosure to give everyone a free software
compatible patent license to implement tls-extractor in non-ECC
situations, that would work too.

If neither happens, and Certicom continue to claim as per BCP79 and in
the #1004 disclosure that they have patents that cover tls-extractor,
and provides no information on non-ECC use about those patents, I would
not support publication without significant more justification that the
Internet community cannot live without a patent encumbered tls-extractor
(comparable to the justification for RSA).

/Simon

---

From: Matthew Campagna <[email-masked]>
Date: Mon, 18 May 2009 10:52:44 -0400

Eric,

  I have updated the IPR disclosure #1004, which should post in a couple of days.  I have modified the patent disclosure and licensing declaration to more carefully delineate which RFCs and I-D contain IP to which the grant pertains.  In particular:

Section IV of the form, "IETF Document or Other Contribution to Which this IPR Disclosure Relates," remains largely unchanged with the exception of updated draft #s.  This is to indicate the broader effected documents to which the license extends.  

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.

   We consider the PDF document the formal IPR statement and invite IETF to host it internally if they believe that inclusion by external link changes the significance of the patent disclosure and licensing declaration.

I believe the confusion arises from interpreting Section IV "IETF Document or Other Contribution to Which the IPR Disclosure Relates."   A possible suggestion to remove future ambiguity might be to codify the form more in RFC 3979, i.e. what is to be included in Section IV and what is meant by "relates."

Regards,
   Matt

Matthew Campagna
Certicom Research
Office: 203.894.9777 Main: 905.507.4220 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Eric Rescorla
> Sent: Monday, May 18, 2009 2:51 AM
> To: Dean Anderson
> Cc: Simon Josefsson; [email-masked]; Nicolas Williams
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 May 2009 17:56:03 +0200

Matthew Campagna <[email-masked]> writes:

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

Thank you, I hope this resolves my concern.

>    We consider the PDF document the formal IPR statement and invite
>    IETF to host it internally if they believe that inclusion by
>    external link changes the significance of the patent disclosure and
>    licensing declaration.

I believe the IETF should host it, if the IETF considers it to be the
BCP 79 disclosure.  Otherwise it has no persistent archive of received
disclosures.  But this is not something you should be responsible for
making happen.

> I believe the confusion arises from interpreting Section IV "IETF
> Document or Other Contribution to Which the IPR Disclosure Relates."
> A possible suggestion to remove future ambiguity might be to codify
> the form more in RFC 3979, i.e. what is to be included in Section IV
> and what is meant by "relates."

I strongly agree here.  BCP 79 requires the disclosure to contain a list
of patents and a list of documents affected by those patents.  The web
page should use consistent terminology to avoid generating future
similar problems.

Thanks,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 May 2009 11:31:38 -0500

> sort of like commercial pilots have the special privilege to fly other

Most of us are not, in fact, allowed to read patents -- our employers
don't allow it.

Therefore either the IPR claim in question is clearly applicable to the
tls-exporter idea generally, or just in so far as it relates to ECC.  If
the latter then IMO the I-D should progress.  If the former, then we
have a problem.

Nico
--

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 May 2009 17:29:41 -0400 (EDT)

That isn't quite accurate. While the documents you list are indeed on 
the disclosure, so is:

Internet-Draft:	"Keying Material Exporters for Transport Layer Security 
(TLS)"  (draft-ietf-tls-extractor-05)

The above is also a factual assertion, made by the IPR 1004 disclosure.

We have just recently learned of this disclosure in relation to
draft-ietf-tls-extractor-05.  The argument that the disclosure was
_filed_ more than half a year ago is inconsequential;  The consequential
fact is that the Working Group didn't consider that IPR in evaluating
draft-ietf-tls-extractor-05, and didn't consider non-patented
alternatives as required by RFC 3979. That is a process failure which
would be a basis for appeal, and is currently a basis for opposing the
draft.

The argument that IPR 1004 only pertains to ECC and that
draft-ietf-tls-extractor-05 contains no ECC urging a conclusion that IPR
Disclosure 1004 can be ignored is a fallacy. The patents can (and do)  
cover more than just ECC.  They may indeed cover
draft-ietf-tls-extractor-05 just as the IPR 1004 says they do.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 May 2009 17:54:57 -0400 (EDT)

> Most of us are not, in fact, allowed to read patents -- our employers

Most? I doubt most. I do understand that /some/ are not allowed to do
so.  Of course, if someone can't participate in IETF IPR analysis due to
job restrictions, that doesn't mean that others are unable to
participate, nor does it mean that IPR analysis should not be performed,
nor does it mean that asking for performance is unreasonable.

Indeed, your company probably has a representative who can participate
in the IPR analysis. I think it would be helpful if you would try to
locate that person in your company and prompt their engagement in this
discussion.

> Therefore either the IPR claim in question is clearly applicable to
> the tls-exporter idea generally, or just in so far as it relates to
> ECC.  If the latter then IMO the I-D should progress.  If the former,
> then we have a problem.

With the exception of the qualifier "clearly", I agree with your
analysis of the logic of the situation.  But we should investigate the
IPR question before we proceed on this draft.

It occurs to me that if your employment agreement prevents you from
reading patents and assuming you have not violated that agreement, then
you are categorically uninformed about the specifics of these patents
and their IPR disclosure and will remain so for the foreseeable future.

		--Dean