Subject: Evaluation: draft-housley-tls-authz-extns-07.txt to Proposed Standard

From: "Dimitrios P. Bouras" <[email-masked]>
Date: Mon, 09 Feb 2009 04:25:29 +0200

Dear Sir's

 I am writing to oppose approval of the patent encumbered authz
extension of the
 TLS authorization protocol as submitted by Mark Brown of "RedPhone
Security"
 and Russell Housley of "Vigil Security LLC", and published in:

    http://tools.ietf.org/wg/tls/draft-housley-tls-authz-extns-07.txt

 I have been alerted to the fact that "RedPhone Security" has applied
for a patent
 which would need to be licensed to anyone wanting to implement and -- more
 importantly -- practice the standard. It is obvious in my mind that
this should be
 by definition unacceptable in an Internet standard, regardless of
whether it is
 proposed as "optional", or as a "proprietary extension". If it is
proprietary -- a
 necessary fact for supporting a patent claim, it can remain in the
domain where
 it originated; there is absolutely no basis for it becoming an Internet
standard.

 In my mind, when the Internet Engineering Task Force (IETF) and the
Internet
 Engineering Steering Group (IESG) evaluate new proposals for standards,
they
 should first and foremost make sure that they are not encumbered by
patents or
 any other sort of restriction that would prevent their use by free
software users and
 programmers. This is not the case with this proposed standard, and I
call upon you
 to *not approve* it on any level unless the patent threat is removed
entirely with a
 royalty-free license for all users

 Sincerely,
 Dimitrios P. Bouras

-- 
*Dimitrios P. Bouras*
*M.A.Sc., Ph.D.*
/Telecommunications & IT
Consulting Services/

*27 EL. VENIZELOU STR.*
*GR-16673 VOULA, ATHENS*
*GREECE* 		*Voice/SMS:* +30 693 743 75 92
*Fax:* +30 210 895 35 52
*Email:* [email-masked] <mailto:[email-masked]>
*http://www.dbouras.eu*
*http://www.linkedin.com/in/dbouras*
*Skype:* Dimitrios.Bouras

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Feb 2009 14:50:45 +1300

FWIW (and it would be good if other actual
IETF participants care to indicate +1 if they agree):

The actual words in RedPhone's current disclosure:

"RedPhone Security hereby asserts that the techniques for
sending and receiving authorizations defined in TLS Authorizations
Extensions (version draft-housley-tls-authz-extns-07.txt) do not
infringe upon RedPhone Security's intellectual property rights (IPR)..."

Now, there's been some discussion of whether some use cases for
the protocol will nevertheless lead implementors to infringe, but
that (plus the question of whether the offered license conditions
in that case are in fact acceptable) is frankly irrelevant. The
draft on the table is in itself unencumbered by RedPhone Security,
and that's all that matters as far as the IETF's IPR rules go.

There may be other reasons not to advance this document; not being
a security person, I have no opinion about that. But as far as this
particular IPR issue is concerned, IMHO it's good to go.

    Brian

---

From: Tim Bray <[email-masked]>
Date: Mon, 9 Feb 2009 21:32:19 -0800

> infringe upon RedPhone Security's intellectual property rights (IPR)..."

I'm wondering why you reproduced this paragraph and omitted the following
six.  This is not a rhetorical question. -Tim

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 10 Feb 2009 01:42:54 -0500

Dear Brian;

> IETF participants care to indicate +1 if they agree):

FWIW I read the IPR statement and couldn't figure out what the recent  
posters
were talking about either.

Hunting around, I come across this

<http://www.heise-online.co.uk/news/FSF-call-for-opposition-to-TLS-Authorisation-standard--/112596 

which lead to this

http://www.fsf.org/news/reoppose-tls-authz-standard

news → Send comments opposing TLS-authz standard by February 11
<snip>

That patent in question is claimed by RedPhone Security.  RedPhone has  
given a license to anyone who implements the protocol, but they still  
threaten to sue anyone that uses it.

<snip>

------

I don't see any sensible way you get from the statement below to the  
statement above.

Regards
Marshall

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

---

From: "Powers Chuck-RXCP20" <[email-masked]>
Date: Tue, 10 Feb 2009 07:32:27 -0500

+1

If the bar for allowing technology to move forward in the IETF is that
it must not only be unencumbered itself, but _any_ use of it must also
be unencumbered, then we may as well all go home, after rescinding TCP,
IP, HTTP, and anything else we have done in the past - these are all
used to do some things that are themselves encumbered. Welcome to the
real world.

If the technology in the document to be standardized is unencumbered,
then the fact that _some_ uses of that technology may run into
encumbered territory is irrelevant, except to those who hate patents in
general.

Regards, 
Chuck 
------------- 
Chuck Powers, 
Motorola, Inc 
phone: 512-427-7261
mobile: 512-576-0008

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian E Carpenter
> Sent: Monday, February 09, 2009 7:51 PM
> To: [email-masked]
> Subject: FWIW: draft-housley-tls-authz-extns-07.txt to 
> Proposed Standard
>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Feb 2009 13:44:37 +0100

> particular IPR issue is concerned, IMHO it's good to go.

I disagree.  The IETF policies around patents mention "use" as well as
"implementation".  Thus, a license that permit "implementation" but not
permitting "use" should generate similar scrutiny and discussion.  It
poses the same problem for actual users.

I strongly disagree with a notion that just because someone grants a
patent license for "implementation" that the IETF community has to
consider the patent situation around the technology as irrelevant.  Use
of technology goes beyond "implementation".  This is acknowledged in the
IETF policy documents.  Compare, e.g., RFC 3979 and in particular the
definition of the term "Covers".

I also disagree with the claim that the draft is unencumbered.  I don't
follow how you reach that conclusion from the patent disclaimer.  You
quoted only one paragraph out of several, and the other paragraphs are
the ones that encumber use of the protocol.  It may be your
interpretation that the draft is unencumbered, but everyone get the same
opportunity to make their own interpretation.  As implementer of the
technology, and having consulted with legal aid, I have made another
interpretation.

/Simon

---

From: <[email-masked]>
Date: Tue, 10 Feb 2009 14:34:09 +0100

Simon Josefsson wrote:

> I disagree.  The IETF policies around patents mention "use" as well
> as "implementation".  Thus, a license that permit "implementation"
> but not permitting "use" should generate similar scrutiny and
> discussion.  It poses the same problem for actual users.
>
> consider the patent situation around the technology as irrelevant.
> Use of technology goes beyond "implementation".  This is
> acknowledged in the IETF policy documents.  Compare, e.g., RFC 3979
> and in particular the definition of the term "Covers".
>
> I also disagree with the claim that the draft is unencumbered.  I
> don't follow how you reach that conclusion from the patent
> disclaimer.  You quoted only one paragraph out of several, and the
> other paragraphs are the ones that encumber use of the protocol.  It
> may be your interpretation that the draft is unencumbered, but
> everyone get the same opportunity to make their own interpretation.
> As implementer of the technology, and having consulted with legal
> aid, I have made another interpretation.

<speaking as an individual, not wearing any hats>

Well, it's good to remember that there are *lots* of patents about
larger systems that include IETF protocols (e.g., TLS, HTTP, MPLS,
Mobile IP, or RADIUS) as components. What's claimed to be novel (and
covered by the patent) is not the IETF protocol as such, but the
combination: using the protocol(s) in certain environment in
particular way to solve something.  And of course there are lots of
implementation technique patents where what's claimed to be novel
(and covered by the patent) is some particular way of implementing
the protocols (e.g. better performance than "obvious" implementations).

Usually these types of patents are *not* disclosed to the IETF, since
the protocol as such is not covered by the patent.

In fact, my guess would be that we probably don't have *any* IETF
protocols where someone has not patented using protocol A in bigger
system B in way C to solve D (where B+C+D is something that the RFC
did not describe, so it could be non-obvious and novel).  If we
required that IETF protocols must not have any such "field of use
restrictions" (where using the protocol in certain way could be
encumbered), we would not publish any protocols at all.

My reading of RedPhone's IPR disclosure 1026 is that they claim to
have a patent application about a larger system that includes
tls-authz as one part, and uses it in particular way. If you want to
build a system matching the numbered list 1..4 in the disclosure
(RedPhone's description of what they claim is covered), then you
would have to consider this IPR disclosure.

However, I think there are many more good uses for tls-authz that
do *not* match items 1..4. Just because someone has filed a patent
application on some rather obscure combination of B+C+D should not
prevent others from using the protocol for things not covered by
that application. Thus, I support publishing this as an RFC (either
Informational or Standards Track).

(BTW, I think it's pretty clear that RedPhone didn't get the
process right here. Some have claimed they did this knowingly with
malicious intent, others have attributed it more to carelessness
and ignorance -- I would say we can't really know without doing
a Vulcan mind meld :-) Either way, I think we should consider
the draft's technical merits and IPR situation *now*, and not
put too much weight on the history.)

Best regards,
Pasi

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 10 Feb 2009 09:48:19 -0500

I agree with Brian and Marshall, but let me introduce a different 
perspective on the issue.

Marshall Eubanks wrote:
> [...]
> 
> I don't see any sensible way you get from the [Brian interprtetation] to the  
> [FSF interpretation].
> 

Maybe it's a matter of ideological objection to patents. Engineering is 
not always rational, ideology sneaks in in various ways, sometimes under 
the name ethic.

So you see a bunch of instantaneous IETF volunteers who whish to bring a 
consensus based on some form of ethic (as they see it, I presume). What 
can the IETF do? Is there some obscure provision in IETF processes that 
can turn down participation based on manifest ideological grounds that 
do not resist analysis from another perspective?

Incidentally, it is intriguing to see the FSF deeply rooted in the 
Copyright foundation (Berne convention) for ensuring legal protection of 
intellectual property, and at the same time so ideologically opposed to 
the patent foundation (Paris convention). But at this point, it becomes 
useless to argue with them about patents.

Some form of procedural integrity should be sought by the IETF if there 
is anything to be salvaged after being victimized by instantaneous 
volunteering based on ideological grounds.

Good luck!

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Feb 2009 16:29:42 +0100

> would have to consider this IPR disclosure.

A license is required for each of the cases 1, 2, 3, and 4 individually.

As far as I read item 3, it seems to cover many kind of realistic use of
this protocol.  As soon as you have some authorization data, you would
typically compare the sender of the authorization to some set of valid
issuers.

> do *not* match items 1..4.

That would change things.  Can you describe a practical way to use
tls-authz that wouldn't be covered by, for example, item 3?  I tried to
understand one unencumbered use-case of tls-authz earlier:
<http://thread.gmane.org/gmane.ietf.general/33561>.  To my reading, the
example seems encumbered.  If you can explain an unencumbered use-case
that would help.

> Just because someone has filed a patent application on some rather
> obscure combination of B+C+D should not prevent others from using the
> protocol for things not covered by that application. Thus, I support
> publishing this as an RFC (either Informational or Standards Track).

Obviously part of our disagreement seems to be what is "obscure".

Would you still support publication if the patent application covers
broader ways to use the protocol?

/Simon

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 10 Feb 2009 12:41:24 -0500

> typically compare the sender of the authorization to some set of valid

This reasoning is perhaps useful to support an opposition campaign, but 
it is incomplete.

The patent *claims* can not be broadened by a generic mention of a use 
case. Going into the details of this specific instance boils down to 
evaluating the validity of IPR claims.

Let me bring a few facts. The redphone IPR is a US patent application 
that was amended on 2008/01/25. No US patent office examiner has 
responded so far. Altough a PCT application is mentioned in the IPR 
disclosure, there is no mention of national phase entry(ies), so the 
only affected jurisdiction would be the US only (the IPR disclosure 
should be more comprehensive if I am wrong). With a priority date in 
January 2005, the IPR claims can not cover the business methods 
prevailing before, e.g. the corporate treasury management on-line 
services based on authorizations (e.g. one-time password using tokens) 
to access a bank account (network resources) where the specific form of 
authorization is defined in the service enrollment agreement.

So, the argument that IPR disclosure 1026 case 3 is a justification for 
the FSF campaign is relevant only in the perspective of an ideological 
opposition to patents. There are ample facts to justify an endorsement 
of TLS-authz advance in the IETF standardization process.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Ofer Inbar <[email-masked]>
Date: Tue, 10 Feb 2009 14:23:06 -0500

Powers Chuck-RXCP20 <[email-masked]> wrote:
> If the technology in the document to be standardized is
> unencumbered, then the fact that _some_ uses of that technology may
> run into encumbered territory is irrelevant, except to those who
> hate patents in general.

I think software patents are a bad idea, and would prefer that there
be none of them.  I think software is like music, and patenting
software is like patenting chords or melodies.  Patents are the wrong
legal tool for software, and they undermine the purpose of IPR (which
is to promote "progress" of the "useful arts").

Nevertheless, I see no reason to oppose standardizing a protocol that
is unencumbered by patents, simply because some uses of that protocol
(even if they may be common) are encumbered.

I think such opposition requires more than mere opposition to software
patents, or to patents in general.  At the very least, it also requires
that one not think through the logical consequences of one's strategy.

In practice, however, I believe most of the people who sent us
drive-by mailings were simply misinformed or mistaken about the facts.
  -- Cos

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Feb 2009 08:41:59 +1300

Tim,

> six.  This is not a rhetorical question. -Tim

Because they don't apply to the document we are being asked about.
We aren't being asked about a document defining use cases.

Whenever you implement *anything* involving *any* standard,
some of the use cases might infringe any number of patents.
That's a problem between the implementor and the patent
holders, and doesn't concern the standards body.

     Brian

---

From: John Levine <[email-masked]>
Date: 10 Feb 2009 21:06:35 -0000

>> aid, I have made another interpretation. ...

>tls-authz as one part, and uses it in particular way. ...

You know, this patent application was published two and a half years
ago.  There's no need to speculate about what it covers.

Am I really the only person here who has taken 15 minutes to read it?

Visit http://patft.uspto.gov/, where it's application number 20060174323

Or the WIPO version is here:

http://www.wipo.int/pctdb/en/wo.jsp?IA=US2006001342&wo=2006081085&DISPLAY=STATUS

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: <[email-masked]>
Date: Wed, 11 Feb 2009 14:50:27 +0100

> A license is required for each of the cases 1, 2, 3, and 4

Well -- if the patent is granted, a license may be required if you
do any of the things listed in the granted patent's claims.  The items
1..4 may or may not be an accurate summary of the claims in the
application, and what's granted may be different from the application.

> As far as I read item 3, it seems to cover many kind of realistic
> use of this protocol.  As soon as you have some authorization data,
> you would typically compare the sender of the authorization to some
> set of valid issuers.
>
> tls-authz that wouldn't be covered by, for example, item 3?  I tried
> to understand one unencumbered use-case of tls-authz earlier:
> <http://thread.gmane.org/gmane.ietf.general/33561>.  To my reading,
> the example seems encumbered.  If you can explain an unencumbered
> use-case that would help.

I have not read the actual patent application (and I'm not planning
to), and as I noted above, I do not know how accurate the four-item
summary is.  Without reading the application itself, saying "here's a
use case that is not covered by the claims" would be rather unwise.

However, draft-ietf-tls-attr-cert-01 (from 1998, predating this
application by many years) describes a use case where the client
presents an AC containing a role or security clearance to the server,
and the server uses this to determine whether the client is allowed to
access the requested resource.

It's of course possible that the patent applications's claims cover
this use case, too -- but personally, I would not be extremely worried
about getting sued by RedPhone if this was the use case I'd be doing.

(Note that draft-ietf-tls-attr-cert-01 also has lot of other stuff
that is not in tls-authz; e.g. about acquiring/issuing ACs, and hints
about what ACs the client should consider presenting. But there's some
overlap as well.)

> > obscure combination of B+C+D should not prevent others from using
> > the protocol for things not covered by that application. Thus, I
> > support publishing this as an RFC (either Informational or
> > Standards Track).
>

I agree that this is a relevant question; if the application would
claim to cover most of the interesting use cases (and only some
obscure cases would be unencumbered), that could change my opinion.

Best regards,
Pasi