RE: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard

[Pasi.Eronen]

Simon Josefsson wrote:

> > 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.
>
> A license is required for each of the cases 1, 2, 3, and 4
> individually.

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.
>
> > However, I think there are many more good uses for tls-authz that
> > 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:
> .  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.)

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

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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard

[Brian E Carpenter]

Tim,

On 2009-02-10 18:32, Tim Bray wrote:
> On Mon, Feb 9, 2009 at 5:50 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
> 
>> 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)..."
> 
> 
> I'm wondering why you reproduced this paragraph and omitted the following
> 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

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard

[Thierry Moreau]

Simon Josefsson wrote:


 writes:



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.



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.



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

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: thierry.mor...@connotech.com

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard

[Simon Josefsson]

 writes:

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

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.

> However, I think there are many more good uses for tls-authz that
> 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:
.  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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard

[Thierry Moreau]

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: thierry.mor...@connotech.com

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard

[Pasi.Eronen]

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



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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard

[Simon Josefsson]

Brian E Carpenter  writes:

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

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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard

[Powers Chuck-RXCP20]

+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: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On 
> Behalf Of Brian E Carpenter
> Sent: Monday, February 09, 2009 7:51 PM
> To: ietf@ietf.org
> Subject: FWIW: draft-housley-tls-authz-extns-07.txt to 
> Proposed Standard
> 
> 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
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard

[Marshall Eubanks]

Dear Brian;

On Feb 9, 2009, at 8:50 PM, Brian E Carpenter wrote:


FWIW (and it would be good if other actual
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




which lead to this

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

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


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.




--

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


Regards
Marshall


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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard

[Tim Bray]

On Mon, Feb 9, 2009 at 5:50 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

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


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


>
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Brian E Carpenter]

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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf