Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07

From: Richard Levitte <[email-masked]>
Date: Sun, 03 Jun 2007 13:37:02 +0200 (CEST)

There's already been enough arguments that I agree with about the
patent issue with this draft from Pasi, Simon and Dean.  I agree with
them all, and just want to add another voice against putting this
draft, as it currently stands with the patent claim, on the Standard
Track, and am in favor of putting it on the Experimental or
Informational tracks.

As a OpenSSL developer, I will oppose implementing authz in it unless
the patent issue is resolved in a satisfactory manner.

Cheers,
Richard

-- 
Richard Levitte                         [email-masked]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
						-- C.S. Lewis

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

---

From: "Mark Brown" <[email-masked]>
Date: Mon, 4 Jun 2007 22:26:37 -0500

Richard,

I see that despite efforts to identify, bracket, and set aside the FUD
concerning the RedPhone Security patent application, uncertainty and doubt
remain.  I'd really like to cut through the FUD.  As I mentioned earlier,
the royalty free GUL only protects a single method of computing a Boolean
authorization result -- a method that I think is new.  Let's put aside fear,
uncertainty and doubt concerning one new method, when every other method --
all methods documented prior to the RedPhone Security patent filing, and
those discussed early in our consensus-building process
(http://tinyurl.com/2pvwgo ) -- are all available royalty-free under the
GUL.  

To put your comment in perspective, SSL was born as a patent (See USPTO
5,657,390, filed August 1995, issued August 1997 http://tinyurl.com/2cnuwv),
has dealt with patent issues throughout its lifecycle (see for example
http://tinyurl.com/26vjnh ), and thrived after Netscape's conditional but
royalty free license grant (see archives like http://tinyurl.com/24olgv ).
FAQ #1 on the OpenSSL website is still, "Do I need patent licenses to use
OpenSSL?" (http://www.openssl.org/support/faq.html#LEGAL1)  Even before the
Netscape SSL patent issued, EAY in 1996 made a list of cryptographic
algorithms that required special attention to IPR issues (
http://tinyurl.com/2ayy7d ).  And since 1997 there have been other patents
that apply to SSL/TLS - for example elliptic curve crypto (Certicom) which
has already been added to several TLS standards-track drafts and RFCs.  What
I think this history amounts to is that OpenSSL and its users can stomach a
handful of "off-limits" algorithms.  It's like a tradition for OpenSSL.. ;-)

There are now implementations of tls-authz in GNUTLS, on OpenSSL and NSS.
Free software carrying tls-authz is growing up around us whether we like it
or not.  Because it's free (libre) no one asked me and apparently they
didn't ask OpenSSL developers either.  Personally, I think that's great -- I
think sending SAML over TLS should be free (libre), and that's why I started
down the standards track in the first place.  No FUD: The GUL is just saying
that tls-authz should not be used to facilitate violations of a patent
pending access control method that I am confident is new.

Isn't a satisfactory resolution of "the patent issue" one where all people
get to use tls-authz royalty free for any purpose and using any non-patented
method?  Isn't that the best possible case?  With the exception of one
method that I expect will become patented, that's what's offered for
tls-authz under the GUL.  

--mark

> -----Original Message-----
> From: Richard Levitte [mailto:[email-masked]]
> Sent: Sunday, June 03, 2007 6:37 AM
> To: [email-masked]
> Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07
>

---

From: Dean Anderson <[email-masked]>
Date: Tue, 5 Jun 2007 19:26:12 -0400 (EDT)

> all methods documented prior to the RedPhone Security patent filing, and
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> (http://tinyurl.com/2pvwgo ) -- are all available royalty-free under the

Those would be the __prior_art__. Of course they are free. They are
available royalty free __without__ the GUL, and without a tls-authz
patent license.  Did you make some mistake? To me, your statement here
is FUD, since there is no need to obtain a GUL to use prior-art.

> 5,657,390, filed August 1995, issued August 1997 http://tinyurl.com/2cnuwv),

Yes, indeed, there are a slew of software patents. These resulted in
Richard Stallman founding the LPF, and ultimately, in RFC3979.  We made
the IETF policy to put an end to the practice of submarine-patented
standards. You seem to have found a unique way around that.

> What I think this history amounts to is that OpenSSL and its users can
> stomach a handful of "off-limits" algorithms.  It's like a tradition
> for OpenSSL.. ;-)

A tradition many people want to end.  But I think we can stomach much
_less_ when we are deceived about the existance of patents by the very
IETF officials in whom we place our trust in their integrity and
honesty.

> There are now implementations of tls-authz in GNUTLS, on OpenSSL and NSS.

I don't want to seem to speak for either GNUTLS, or OpenSSL, but it
seems to me like they are against this standard, and that all
implemented it without knowing of the patent application; so I wonder if
there might be fewer implemenations of tls-authz shortly.

> didn't ask OpenSSL developers either.  

Huh?????  Perhaps they didn't ask because they didn't know about the
patent because it was improperly concealed by an IETF official who
really should be fired for his bad faith.

But, I think it is not too late to stop tls-authz, if that's your point.

> Personally, I think that's great -- I think sending SAML over TLS
> should be free (libre), and that's why I started down the standards
> track in the first place.  No FUD: The GUL is just saying that
> tls-authz should not be used to facilitate violations of a patent

Are you telling us that the PAS functions are subject to a patent
application?

> method?  

Yes, that would be satisfactory. To do that, you have to grant a royalty
free license to the public, and drop the nonsense about an "offer of a
free GUL on request".  And drop the restrictions on PAS functions from
the GUL, too. I note that you've seen the Netscape license, and I don't
know why anyone would agree to less.

> With the exception of one method that I expect will become patented,
> that's what's offered for tls-authz under the GUL.

Umm.  Actually, No, that isn't what's offered by your cereal-box offer
to give a free GUL on request.  You haven't offered any license to the
public, and RPS can't be compelled to complete the GUL in the future by
your "offer".

		--Dean

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

---

From: Nelson B Bolyard <[email-masked]>
Date: Tue, 05 Jun 2007 19:25:57 -0700

>> There are now implementations of tls-authz in GNUTLS, on OpenSSL and NSS.

I interpreted that statement to mean that others (besides the authors and
principal developers of OpenSSL and NSS) have developed tls-authz as their
own extensions to those open sources.  I did NOT interpret it to mean
that the base distributions of OpenSSL and NSS now implement tls-authz.

Mr. Brown: Did you intend to state that tls-authz is now available in NSS?

> implemented it without knowing of the patent application; 

There is no tls-authz in NSS, at least not in the official NSS source
repository operated by mozilla.org.  I would know if there was.
http://www.mozilla.org/owners.html#security

> so I wonder if there might be fewer implemenations of tls-authz shortly.

/Nelson

---

From: "Mark Brown" <[email-masked]>
Date: Wed, 6 Jun 2007 11:09:08 -0500

Dean,

It sounds like you're expecting that the RedPhone Security patent will issue
as filed but that it really doesn't contain any innovation -- i.e. that the
patent grantors of the world will screw this one up.  I'm less cynical on
this question, and so on that point I have to disagree with you.

I don't see eye to eye with your cynicism about patents and/or their
grantors; instead, I'm passionate about authorizations technology.  I think
federated authorization & identity techniques are fascinating and are likely
to be very useful in the future of Internet communications.  I love my job.
It energizes me because I fully intend to bring useful products to market --
even though that's difficult to do as a small company.  I may fail, but I'll
try.  My country -- at least historically -- thought that patents were a way
to encourage this sort of passion because historically it's been the cradle
of innovation.  That's the spirit behind what I'm doing, and I hope we can
find a way to respectfully disagree about the systems supporting patents and
the RedPhone Security filing in particular.

> free GUL on request".  

It's taken me a while to understand your criticism on this point, but I
think I get it now.  I have prepared a corrected license which will be ready
and published shortly (or ASAP at the latest).

> ..And drop the restrictions on PAS functions from

I've modeled after the Certicom ECC license instead of the Netscape license,
which admittedly gives away less than Netscape did, but I think ECC has been
pretty well received all the same.  I feel a need to reserve one method of
verifying authorizations as described by the PAS functions.  Please don't
exaggerate what I'm reserving (the PAS Functions); it really is possible
that there are better ways to use tls-authz than the method I'm reserving. 
 
> public, and RPS can't be compelled to complete the GUL in the future by

I hope the corrected license will address your concerns.  I think I
understand your concern that RedPhone Security, or its successors etc.,
won't grant requests for licenses.

--mark

---

From: Dean Anderson <[email-masked]>
Date: Fri, 8 Jun 2007 16:43:13 -0400 (EDT)

Also I have learned that not everyone on the TLS list knows the history
of the draft, particularly the misbehavior. I'm going to put up a web
page on http://www.av8.net/IETF-watch/People/Housley/ to document this.

Inline

> this question, and so on that point I have to disagree with you.

I'm not cynical about the PTO 'screwing it up' (see also the
clarification below). But as president of the LPF, it is true that I've
seen many patents issue that aren't novel, and many that are finally
found to be invalid after being litigated or on review after issue.  
The patent office, to its credit, reviews such bad patents when
complaints are made after issue. But the fact is, that there are very
few novel software inventions out there.  The reason, I think, that
there are more bad software patents than other kinds of patents is
because it is easier for software writers to invent their own terms
which foil patent searches--there have been some interesting proposals
(one was a new language) to solve that problem, but none that are fully
workable [other than, of course, eliminating software patents].

But I do see novel software patents, now and again.  Those few novel
inventions create the most concern for the LPF and others, because when
an invention is truly novel, it is often very difficult to come up with
another alternative that is competitive.  A good example is the Fourier
Transform and the Fast Fourier Transform (FFT).  Once you have a patent
on the FFT, its pretty hard to compete using the old transform method.  
A novel invention usually has a benefit that isn't found anywhere else;
the benefit might not be performance, but it is something that makes the
invention "better", and that something is also novel.  A good example of
a not-novel patent is the infamous XOR patent, where ATT patented the
use of XOR to update a graphical mouse pointer image. [the patent office
rescinded that patent on review]

By contrast, your authz-extns claims aren't really novel: You didn't
invent federated authorization and identity. You didn't invent using
X.509 information for authorization.  There is nothing novel about
moving around X.509 certificate information. We do that all the time
without TLS extensions.  X.500 and LDAP use certification information
for authorization.  Anyone trying to implement say, RADIUS over TLS,
would have to carry most/all of the same steps.  There is nothing novel
about using authorization with TLS. Almost all web apps do that to some
extent.  Every step in your patent specification is dictated by the TLS
protocol, or by the steps required for authorization as determined
previously in other applications.  So, you haven't invented anything;
what you have is really a copyright on a sequence of obvious steps;
steps that would be obvious to anyone trying to perform authorization
through a TLS protocol extension.  There is nothing clever or inventive
in what you've done.  There is no secret to reveal in the patent. What
you have is an 'obvious first use'.

What is an 'obvious first use'?

For example, the first person to send HTTP over 10GigE is not entitled
to a patent on sending HTTP over 10GigE, even though they are the first
person to do so.  The only novelty is being the first to do something
obvious. Similarly, the only "first" in your patent, is being the first
to send authorization information using a TLS extension.  The patent
office is supposed to recognize this sort of non-patentable 'obvious
first use', but often does not do so until the patent is later
challenged.  

So, my view isn't cynicism, but long experience with the patent office.  
The patent office is well aware of its limitations, and honestly works
very hard to improve its processes. And the PTO has improved a lot since
the LPF was first founded.  When we began our efforts, the PTO didn't
hire software people, and had no computer scientists on staff to judge
software patents. That's how the infamous XOR patent got issued (and was
ultimately revoked on review).  The PTO responded to criticism, and
began hiring computer scientists to review software patents. When the
LPF first began, the PTO didn't publish patent applications until after
the patent was granted.  The fact that your patent application is
public, is a result of the PTO trying to improve its process in response
to criticism by the LPF and others. Things are much better now, but a
lot still slips though first review. This too, is changing, but slowly.

Clarification on 'likely to issue'

You also mentioned something about my statement that patent was 'likely
to issue' indicating cynicism. This needs some clarification. My
statement is not cynical.  It is not the case that I expect the patent
office to "screw it up"---in fact, the PTO will try hard to fix what
their mistakes after issuing a bad patent. It is true that I don't think
your patent is worthy of issue, but that is not what I mean when I talk
about 'likely to issue'; nor is it that I am second guessing the patent
office; When I say 'likely to issue', I mean that as a matter of our own
preparation, the patent office has published a live patent application,
and we have to anticipate that this patent will happen;  This is the
purpose pre-issue publication--to give us advance warning.  We
anticipate this on all published applications.  I mean 'likely to issue'
in the same sense as a live grenade is anticipated to explode, and would
be 'likely to explode'.  It could be a "fake grenade", but we can't
assume that.  We have been given notice by the PTO of something that
will 'likely happen', and have to act accordingly to minimize our
exposure to the anticipated patent.  This is the purpose of publicizing
the application before issuance.

> I think federated authorization & identity techniques are fascinating
> and are likely to be very useful in the future of Internet
> communications.

Federated authorization and identity techniques have been important in
the past, and I'm sure they will be important in the future.

> I love my job. It energizes me because I fully intend to bring useful
> products to market -- even though that's difficult to do as a small
> company.

I love my job, too. And I run a small company, too.  And I play by the
rules and I work really hard, and I contribute to community projects
like the LPF. And like others who also work really hard and play fairly,
I take some offense at people who cheat and expect not to be penalized.

> I may fail, but I'll try.  My country -- at least historically --
> thought that patents were a way to encourage this sort of passion
> because historically it's been the cradle of innovation.

Your passion does not entitle you to a patent or a monopoly. Other
people also have a passion for federated authorization and identity, and
for TLS and SSL, and would like to engage their passions without being
monopolized.

> That's the spirit behind what I'm doing, and I hope we can find a way
> to respectfully disagree about the systems supporting patents and the
> RedPhone Security filing in particular.

That is not entirely the spirit of what you are doing. You (that is,
your company, associate, contractor) have cheated by not revealing your
patent application to the IETF when you submitted your draft 7 times,
each time stating there were no undisclosed patents. While the writing
author (Housley) may be more at fault personally than you are personally
at fault, you and your company still bear the burden of the failure,
just as your business partners bear the burden of your personal failures
as CEO.  There has to be a penalty for that misbehavior, otherwise it
would be unfair to those who worked hard, played by the rules and
disclosed their patents as required.

I have learned that not everyone on the TLS list knows the history of
the draft, particularly the misbehavior. I'm going to put up a web page
on http://www.av8.net/IETF-watch/People/Housley/ to document this.

> and published shortly (or ASAP at the latest).

I look forward to seeing this. I should note, though, that resolving the
patent issue won't resolve the cheating issue, and won't absolve Housley
of the bad faith issue.

		--Dean