Leland V. Lammert <[EMAIL PROTECTED]> suggested, again:
>> Another option - puchase the RedHat secure server for $149, and throw it
>>away (retaining the license, of course). That way, you WOULD be legal with
>>openssl.
Dave Neuer <[EMAIL PROTECTED]> demurred:
>I have seen this idea tossed around on this list and on the mod_ssl list,
>that somehow licensing RHSWS or Raven allows one to use *any*
>implementation of RSA. I personally don't see any factual or legal evidence
>to support this conclusion. It seems that with all of these products, (and
>with their crypto toolkits, too), RSA is licensing you "software", not
rights to
>an algorithm. That software that they are licensing you happens to use their
>patented algorithm (which is certainly lawful, since they own the patent,
>and the software). You have a right to use the algorithm ONLY because you
>have a right to use the *software* that you licensed from them.
Ummm. Not quite. The license that matters, of course, is the license
Red Hat, as the OEM, got from RSA Security when it negotiated access, first,
to the RSA BSAFE routines, and then, quite recently, for the right to
include Eric Young's BSAFE SSL-C (with the SSLeay API) in its RH Secure
Server. The terms of those deals were not disclosed, AFAIK... other than a
brief announcement that RSA Labs will work with Red Hat engineers to assist
in the integration of eay's BSAFE SSL-C into the RH Secure Server (RHSS).
Anyone who has tracked RSA licensing over the years, however, knows
that RSADSI has traditionally licensed a single *application* use thru OEMs
like Red Hat -- with the OEM forbidden to expose RSApkc functionality in
such a way as to make it possible for anyone to use it as an API (and thus,
as a mechanism to bypass RSA licensing.)
As Dave recalled:
> Preston Brown of Red Hat [...]
> told me that the reason that they distribute RHSWS as a statically-linked
>binary only, with source just for the apache part (rather than with the
>crypto part as a binary DSO, so that the server could be recompiled, as some
>vendors do), is that their license with RSA prohibited it; it seems RSA
>wasn't keen on the idea that the user might have some discreet crypto lib
>lying around on their system that they could try to put to arbitrary uses.
Over the past 15 years, there have doubtless been exceptions, as
well as flawed contracts and sundry screwups. RSADSI was pretty much the
pioneer in defining modern IP in crypto. It gave away some things free
(like Rivest's MD4 and MD5); it tried copyrights; it tried trade secrets
(RC2, RC4); and it tried patents: RSApkc in the US, early on; now RC5 --
and probably RC6, if it doesn't become the AES. It's core business,
however, was always OEM deals which allow an end user to use RSA
cryptosystems within a specified product.
A better sense of context for RSADSI should be available here in the
virtual heart of the SSLeay/OpenSSL community. While there are divergent
interests at obvious levels, the emergence of SSLeay (like the PGP and SSH,)
was a historical phenomena -- petty legal details to the side -- that binds
these huge international communities of crypto developers, implementors,
users and vendors to RSADSI. They share a common heritage. They promote a
common future. I think RSA acknowledged that, last year, when it recruited
Eric Young (eay) and Tim Hudson from C2 to rework SSLeay into BSAFE SSL-C,
and to establish RSA-Australia.
C2 had exploited a commercial RSAREF license from Consensus -- which
was then sublicensing RSAREF under a deal with RSADSI -- in ways that RSA
had not foreseen (to market, in the US, first Ben Laurie's Apache-SSL; then
Thawte's Sioux -- which evolved into Stronghold with enhancements from
UKWeb.) RSAREF was supposed to be an academic "proof of concept"
implemention. Even the commercial version of RSAREF was not designed to be
efficient, and was only sold with connection-count restrictions that were
expected to lock it into low-end environments. C2's design absorbed those
restrictions, but nonetheless got around them to offer basic SSL
functionality for webservers.
Greg Boiles, who was C2's General Counsel, noted recently that it was
only then, in February of '97, that C2 negotiated a quiet deal with RSADSI
in which C2 got an unusual bare-bones patent license to use any non-RSA
implementation of RSApkc (and another for legal access to Rivest's RC2 and
RC4).
As I recall the story -- and Greg, Ben, or others can correct me --
it was C2 which proved to RSADSI that the commercial RSAREF code, despite
its limitations, could be used to undercut the OEM licensees, placing RSA's
income in real jeapordy. (Shortly thereafter, in mid-'97, RSADSI cancelled
its commercial RSAREF resale deal with Consensus, as someone noted earlier.
Consensus then started selling its own BSAFE-enabled toolkits.)
Dave had a few details wrong -- the Red Hat license was probably
still cast in the traditional terms -- but with the RSAPKC patent due to
expire next fall, I still think his interpretation of the RH deal (and
other recent big RSA license deals with the likes of Intel, or the Israeli
Firewall vendor, Checkpoint) makes a lot of sense.
It stands to reason that whatever was paid for RSA's BSAFE and BSAFE
SSL-C in these OEM deals -- as opposed to any similar deal ten years ago --
was more for the RSA-branded implementation code than it was for rights to
the RSApkc patent, with only the few months left on the US patent.
After years of juggling its IP defenses, RSADSI finally recognized
that its natural strength lay in a mix of patent protection, trade secrets,
and brand name. There may be some dispute over how RSA Security can claim
the name RSA, but the essence of "branding" is to associate a
vendor/developer with its development efforts and investment in a product.
Nothing will deny RSApkc, unencumbered, to the US market, come September
--but nothing will block RSAS from clearly identifying itself as the company
that developed RSApkc and the seminal Public Key Cryptographic Standards
(PKCS) either.
RSADSI has always sold a lot of DES code -- DES code crafted by
Eric Young (eay) and licensed to RSADSI while Eric was working on SSLeay;-)
Today, RSA makes good money selling 3DES implementations to leading US and
international financial institutions. (I'm not sure about Checkpoint, but
Intel almost surely won't even offer crypto-in-a-chip products which exploit
its RSA license until after the MIT patent expires.) Some, then, might ask
why did they license the RSA crypto?
OEMs and others think they get added value -- the ability to lure
and reassure customers and various overseers -- if they buy their
implementation code from the same folks who defined the PKCS standards; the
same folks who developed the MD and RC crypto series; the same folks who
came up with S/MIME, SET, etc. Today, lmost all buyers know, or quickly
learn, that cryptosystems are successfully attacked thru flawed
implementations much more often than thru attacks on the algorithm, per se.
Frankly, many buyers require a supplier willing to accept significant
liability; able to contractually guarantee further development and
compatability. That it "seems to work" is not a sufficient validation for
critical infrastructure, as Schneier has argued in several brilliant essays.
Dave also noted:
>The license that comes with RHSWS 2.0[...] expresses RSA's intent to limit
>the licensee's rights to use the "Software". Add that to the fact that, AFAIK,
>RSA has *never* licensed anyone to use their own implementation of RSA in
>the US (one must always license BSAFE), and I'd say even a lawyer (one of
>which I am not) would have a hard time arguing that buying RHSWS in any
>way grants you rights to use any other implementation of RSA's patented
>algorithms.
Again, Dave's conclusion is -- as Greg Boiles crisply affirmed --
quite accurate, but some of the details are a little off. C2, as noted,
was one company which got a license which allowed it to use any
non-RSA-coded implementation of RSApkc in SSL.
There was actually a time when such licenses were quite common --
several large OEMs (IBM, AT&T, and Microsoft among them, I think) first
licensed only access to the patented process and various other RSA
proprietary cryptosystems. Almost all of them, however, later returned and
extended their license so that they could use the RSADSI implementation code.
(Some doubtless wanted to guarantee compatability with the RSA
toolkits which were in wide use. Many found they could leverage the fact
that the implementation code was written by the RSA Labs team which had
created the model public key crypto implementation standards, RSA's PKCS
series: <http://www.rsasecurity.com/rsalabs/pkcs/>
Personally, I don't think the importance of the PKCS can be
overestimated. Largely because of the hostility of governments to strong
crypto, RSADSI was forced to be much more than a mere inventor, although it
was that too.
Ever wonder why it was left to RSA Labs to develop what became the
defacto standards for public key crypto implementions? Why RSA was faced
with the challenge of developing -- or failing to develop -- model PKC
implementations, and the protocols to exploit them? Why the digital
signature standards are only a couple years old? (Why there is _still_ no
viable ANSI or IETF standard for Diffie-Hellman key agreement!?!)
Projecting today's bias backwards in time, some might suggest it was
the fact that RSApkc and D-H were both patented -- but, in fact, both
national and international standards orgs were not particularly hostile to
proprietary tech. Usually, they only required that users be able to get
ready and inexpensive access to it. (At various stages of any real
standardization process, as well, it might have been possible to negotiate
much more open licenses from RSASDI.)
It was the spooks, plain and simple. The US National Security
Agency has had a iron grip on the US standards-making process, particularly
on anything to do with crypto. RSADSI had to take responsibility for
developing RSA public key crypto into a workable security tool -- long
before any non-governmental crypto community emerged in the industry -- or
let the technology sit on a shelf, as so many other communication systems do.
I did a stint as IBM's industry historian, back when. I vividly
recall how angry the NSA's (voting) reps on the X.9 subcommittee were when
IBM took the export-friendly lead in the ANSI vote to approve the ISO's
adoption of DES as an international standard. They had to face down US
intelligence officials who openly impuned their patriotism. (And then, the
pro-DES vote in X.9F (I think) was mysteriously forwarded to ISO as an
abstention. Meanwhile the ISO, under multiple pressures, decided that its
communications standards should not include cryptosystems. Today, probably
only paranoids can realize how weird to norm was then;-)
I know it is fashionable to demonize RSADSI here, particularly among
those who disagree with software or crypto patents, or those who want to
freely buy or sell strong crypto the US. I'm not trying to convince anyone
that they don't have a real conflict of interests with RSAS; or that their
issues are trivial; or that there are easy resolutions. I also have an
overt bias. For most of the past decade, I've been a consultant to Security
Dynamics, the infosec firm that bought RSADSI in '96. (This year, as its
core product line evolved from SecurID tokens to PKI, SDTI renamed itself
after its best-known subsidary to become "RSA Security, Inc.")
Brian, the RSAS sales guy who tossed that NastyNote at Lee a few
weeks ago, may have sounded like IP for crypto came down from Mt. Sinai on a
graven tablet -- but even at RSA, most realize that the choice of copyright
and then patents as IP options for cryptosystems involved a complex
political negotiation. There were a lot of alternatives proposed in the
1970s. (IBM, I recall, wanted something like a 7-year "patent" for software
innovations.) The choice to extend the traditional IP categories to include
these potent new industrial abstractions was just that, a political
compromise, as commercial Law often is.
(Although this legal maneuver had broad and subtle international
implications that were, and will be, far more important that the US-centric
concerns that define most debates about RSApkc, crypto, and patents.)
Many of the models for RSA's license negotiations came out of the
long years before the Internet boom, when RSADSI was something like ten guys
in San Mateo, a minnow among the firms it sold to and serviced. I think the
only reason one of the whales didn't swallow RSA was that they were
convinced the NSA was going to squash whomever owned that patent. The NSA
went to great lengths to block widespread adoption of public key crypto, and
particularly RSAPKC: stalling all standards; trying to buy RSADSI off and on
-- then finally directly funding competitive cryptosystems (Capstone,
Fortezza, DSA) in blatent attempt to crush the RSADSI.
When the Internet exploded, the street-fighting survival skills
became the basis for a triumph of strategic marketing. I've always believed
that it was not until RSADSI prez Jim Bidzos bet on Netscape and SSL --
offering free use of the RSA cryptosystems for one percent of a Seer's
vision of SSL-enabled Netscape -- was RSA's place in the Internet secured.
Until then, I think Diffie-Hellman (with ElGamal or DSA) had an even shot
at becoming the Net's cryptographic mainstay.
Now, Cylink -- which owned the Diffie-Hellman patents and was
RSADSI's most bitter and most effective competitor -- has the former Deputy
Director of the NSA, the gentleman who managed the NSA's long campaign to
control crypto, as its president. It isn't a fashionable view, but I've
believed for years that it is only _because_ the RSA public key cryptosystem
was patented and privately held for all these years that unGAKed RSA-enabled
cryptosystems may be widely available to offer us trustworthy and secure
e-commerce for the new Millenium.
Didn't mean for this to run on so, but it's now the wee hours of
a holiday eve. I beg your pardon for any pedantic airs that crept in;
summary histories seem to foster them. I trust any errors will be pointed
out to me;-) This is the beginning of the Thanksgiving holiday for us here
in the States; a time to take stock and appreciate what exists. I thank the
Lord for PK crypto and the potential of privacy and e-com prosperity it
holds for my kids. I give thanks, also, for SSLeay, OpenSSH, and RSADSI all.
Suerte,
_Vin
--------
"Cryptography is like literacy in the Dark Ages. Infinitely potent, for
good and ill... yet basically an intellectual construct, an idea, which
by its nature will resist efforts to restrict it to bureaucrats and others
who deem only themselves worthy of such Privilege."
_A Thinking Man's Creed for Crypto _vbm
* Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]> *
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
