Mailing List Archive

Using GPG in the US
I have a few questions. I tried to answer them for myself by checking
the archives and the PGP5-GPG HOWTO, but if they were answered there, it
wasn't clear to me. So if I'm asking a really common question, please
put up with me.

1) Is it legal for me to use GPG in the US? I would think so, but all
the download servers are outside of the US, and I am not sure if I am
allowed to download from one of those. If it is legal to use GPG in the
US, from where can I legally download it?

2) Is there any way I can exchange encrypted messages with PGP users
without installing PGP myself to retrieve keys and fingerprints, and to
prepare them for import into gpg?

Thank you in advance.

- Jimmy Kaplowitz
jkaplowitz@softhome.net
Re: Using GPG in the US [ In reply to ]
On Sun, Nov 22, 1998 at 09:51:47PM -0500, Jimmy Kaplowitz wrote:
> I have a few questions. I tried to answer them for myself by checking
> the archives and the PGP5-GPG HOWTO, but if they were answered there, it
> wasn't clear to me. So if I'm asking a really common question, please
> put up with me.

Okey.

> 1) Is it legal for me to use GPG in the US? I would think so, but all
> the download servers are outside of the US, and I am not sure if I am
> allowed to download from one of those. If it is legal to use GPG in the
> US, from where can I legally download it?

Yes, you can use it (just not the RSA and IDEA plugins) in the US.
There are several problems that PGP has faced over the years:
1) Patented code in the RSA and IDEA algorithms. Fortunately, last
year Diffie-Hellman expired and the ElGamal variation on it has
no patent claims. There is a (non-credible, IMHO) claim that
the Digital Signature Standard is patented, but NIST says its
not and that it's freely available. Since PGP5 moved to (mostly)
Elgamal and CAST5 the patent issue is moot.
2) Export laws. Can't have the badguys like Werner having crypto, so
you can't export it. (Unless it's on paper....) That's why the
real work is not done in the US. You can -import- it all you
want, just tell your friends abroad to get it themselves instead
of sending them a copy.

Because of the export laws, no one in the US will put it up for FTP
(where bad guys can get it). So ftp it from Germany or the UK or
wherever. This keeps GPG free of both points above.

> 2) Is there any way I can exchange encrypted messages with PGP users
> without installing PGP myself to retrieve keys and fingerprints, and to
> prepare them for import into gpg?

Yep. The only thing I use PGP for is compatibility testing. The
current release works quite well in getting along with PGP5.

I use this script to grab keys:
#!/bin/sh
#
# gpget -- fetch the key listed on the command line

/usr/bin/GET http://pgpkeys.mit.edu:11371/pks/lookup\?op=get\&exact=on\&search=$1 | gpg --import

(Okay, so it's stupid, but I couldn't make aliases do it right....)

You may need to replace GET with 'lynx -dump' or some other web fetcher.
GET comes with the Perl LWP module. And, yep, that's grabbing keys from
a PGP5 server.

Using Mutt, PGP/GPG stuff is automatic. My only problem is that Mutt
doesn't let me use 'encryptself' so I can't read what I send unless I cc
myself, but I may hack a patch for that.

--
Brian Moore | "The Zen nature of a spammer resembles
Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
Usenet Vandal | is higher up on the evolutionary chain."
Netscum, Bane of Elves. Peter Olson, Delphi Postmaster
Re: Using GPG in the US [ In reply to ]
On Sun, 22 Nov 1998, Jimmy Kaplowitz wrote:

> 1) Is it legal for me to use GPG in the US? I would think so, but all
> the download servers are outside of the US, and I am not sure if I am
> allowed to download from one of those. If it is legal to use GPG in the
> US, from where can I legally download it?

IANAL, but, there are no domestic laws regarding the use of encryption (of
any strength) in the US by US citizens--at least in the abstract sense.
Encrypting files and sending them to another person is perfectly 100%
legal (IANAL).

The reason the servers that offer crypto for download are outside the US
is that the one thing that IS illegal is the EXPORT of software that
provides 'strong encryption' without a license from the BXA. In the
opinion of the US government, making strong crypto available for download
to foreigners is in violation of that. Hence the foreign servers.

*Using* GnuPG, or PGP and sending encrypted data is not illegal in and of
itself. Of course I'm sure that there will be similar legislation enacted
along the lines of felony-with-a-gun laws that will exacerbate any
criminal charge if you used crypto while performing the act. But that's
an issue to write your congressman about. (As is the ITAR/EAR.)

I STRONGLY recommed that you read the brief papers that come with PGP as
part of the documentation, and in fact I would encourage Werner to make
links to a copy of it off of the GnuPG sites as it touches upon this
issue.

> 2) Is there any way I can exchange encrypted messages with PGP users
> without installing PGP myself to retrieve keys and fingerprints, and to
> prepare them for import into gpg?

I believe there is a way to request keys from key servers using email
instead of hkp tools. Unfortunatley, that's where my knowledge ends. You
might try <http://www.pgp.net> for more information. That's the top level
site for the nework of PGP key servers.

C=)

P.S. ITAR/EAR =~ International Trafficing in Arms Regulations
Export Arms Regulations

--------------------------------------------------------------------------
Heuer's Law: Any feature is a bug unless it can be turned off.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: aiiieeeeeee!!!
--------------------------------------------------------------------------
Early bird gets the worm, but the second mouse gets the cheese.
Re: Using GPG in the US [ In reply to ]
Thanks, Brian, and everyone else who responded to my questions. (I guess
that would be you, Casey :) The replies were very helpful. One further
question, though. What are the RSA and IDEA plugins, why can't I legally
use them in the US, and is there some legal way to get that
functionality with GPG in the US?

Again, thank you all so very much.

- Jimmy Kaplowitz
jkaplowitz@softhome.net

brian moore wrote:
>
> On Sun, Nov 22, 1998 at 09:51:47PM -0500, Jimmy Kaplowitz wrote:
> > I have a few questions. I tried to answer them for myself by checking
> > the archives and the PGP5-GPG HOWTO, but if they were answered there, it
> > wasn't clear to me. So if I'm asking a really common question, please
> > put up with me.
>
> Okey.
>
> > 1) Is it legal for me to use GPG in the US? I would think so, but all
> > the download servers are outside of the US, and I am not sure if I am
> > allowed to download from one of those. If it is legal to use GPG in the
> > US, from where can I legally download it?
>
> Yes, you can use it (just not the RSA and IDEA plugins) in the US.
> There are several problems that PGP has faced over the years:
> 1) Patented code in the RSA and IDEA algorithms. Fortunately, last
> year Diffie-Hellman expired and the ElGamal variation on it has
> no patent claims. There is a (non-credible, IMHO) claim that
> the Digital Signature Standard is patented, but NIST says its
> not and that it's freely available. Since PGP5 moved to (mostly)
> Elgamal and CAST5 the patent issue is moot.
> 2) Export laws. Can't have the badguys like Werner having crypto, so
> you can't export it. (Unless it's on paper....) That's why the
> real work is not done in the US. You can -import- it all you
> want, just tell your friends abroad to get it themselves instead
> of sending them a copy.
>
> Because of the export laws, no one in the US will put it up for FTP
> (where bad guys can get it). So ftp it from Germany or the UK or
> wherever. This keeps GPG free of both points above.
>
> > 2) Is there any way I can exchange encrypted messages with PGP users
> > without installing PGP myself to retrieve keys and fingerprints, and to
> > prepare them for import into gpg?
>
> Yep. The only thing I use PGP for is compatibility testing. The
> current release works quite well in getting along with PGP5.
>
> I use this script to grab keys:
> #!/bin/sh
> #
> # gpget -- fetch the key listed on the command line
>
> /usr/bin/GET http://pgpkeys.mit.edu:11371/pks/lookup\?op=get\&exact=on\&search=$1 | gpg --import
>
> (Okay, so it's stupid, but I couldn't make aliases do it right....)
>
> You may need to replace GET with 'lynx -dump' or some other web fetcher.
> GET comes with the Perl LWP module. And, yep, that's grabbing keys from
> a PGP5 server.
>
> Using Mutt, PGP/GPG stuff is automatic. My only problem is that Mutt
> doesn't let me use 'encryptself' so I can't read what I send unless I cc
> myself, but I may hack a patch for that.
>
> --
> Brian Moore | "The Zen nature of a spammer resembles
> Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
> Usenet Vandal | is higher up on the evolutionary chain."
> Netscum, Bane of Elves. Peter Olson, Delphi Postmaster
Re: Using GPG in the US [ In reply to ]
On Mon, 23 Nov 1998, Jimmy Kaplowitz wrote:

> Thanks, Brian, and everyone else who responded to my questions. (I guess
> that would be you, Casey :) The replies were very helpful. One further
> question, though. What are the RSA and IDEA plugins, why can't I legally
> use them in the US, and is there some legal way to get that
> functionality with GPG in the US?

I can't speak about IDEA, but RSA is patented in the US. That means that
to use it you must have a license from the patent holders. Without that
license, under US intellectual propertly laws you would be infringing upon
the creator's (patent holder's) rights of sole exploitation of something
they devised. In a short while (2 years?) the RSA patents will expire as
well and then there will be no restriction upon use.

Traditionally patents applied to things (machines, mechanisms, etc.) and
so the person who was in violation of the patent hoders rights was the
person who manufactured similar products and sold them. Effectively
stealing the ideas and innovations of another person.

The concept behind patent law *was* that in order for society to advance
as fast as possible, good ideas shouldn't be kept secret. Someone who
built a better mousetrap may not make a product out of it for fear that
someone with more money or resources would be able to co-opt the
technique. That being viewed as 'unfair' necessatiated a legal remedy.

The Patent and Trademark Office served as a vehicle for inventors to
patent good ideas (and bad ones) so that industry could see what was
available and license (or buy) the patent from the holder.

With software, the whole scheme gets screwed up. It effectively becomes a
license to use software, without which you are infringing upon the owners
right to decide who gets to use his ideas.

As luck would have it, patents do expire (17years?) and cannot be renewed.

Patents have become a technique to prevent competitors from being able to
compete with new products. Witness ink jet printers. HP(?) invented them
and then took out over 100 patents on things like the way of making ink
flow through the cartridge and squirt onto the paper. These patents on
every single minutiae of the product effectively barred competitors from
the market until they came up with a product that does the same thing,
only differently. Carefully tip-toeing around the various patents. As
luck would have it, this was a good thing. HP being content in their
protection via patents and their lock on the laser printer market stopped
innovating in that area. Others, however, faced with the challenge of not
being able to do it the easy/obvious way had to actually compete and
innovate. That's why you can get an Epson inkjet printer that will do 720
by 1400 DPI for less than 100USD, but HP only offers a paltry 600x600 or
so at two to three times the cost.

Well, that strayed.

C=)

P.S. The name is CasKey :-)
-----------^

--------------------------------------------------------------------------
"Premature optimization is the root of all evil" -Donald Knuth
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: aiiieeeeeee!!!
--------------------------------------------------------------------------
If you want to build a ship, don't drum up people together to collect wood
and don't assign them tasks and work, but rather teach them to long for
the endless immensity of the sea. -- Antoine de Saint Exupery
Re: Using GPG in the US [ In reply to ]
At 5:06 PM 11/23/98, Jimmy Kaplowitz wrote:
>Thanks, Brian, and everyone else who responded to my questions. (I guess
>that would be you, Casey :) The replies were very helpful. One further
>question, though. What are the RSA and IDEA plugins, why can't I legally
>use them in the US, and is there some legal way to get that
>functionality with GPG in the US?

>> 1) Patented code in the RSA and IDEA algorithms. Fortunately, last
>> year Diffie-Hellman expired and the ElGamal variation on it has
>> no patent claims. There is a (non-credible, IMHO) claim that
>> the Digital Signature Standard is patented, but NIST says its
>> not and that it's freely available. Since PGP5 moved to (mostly)
>> Elgamal and CAST5 the patent issue is moot.

At the risk of sounding like a jerk, the answer seems pretty clear:

These are patented technologies. The holders of these patents can bring
suit against people who use them without paying license fees. The only
legal way to use them is to contact RSA (the company) and pay them big
piles of money. I assume IDEA is similar, but am not familiar with IDEA.

-- "TANSTAAFL" Rich lynch@cognitivearts.com webmaster@ and www. all of:
R&B/jazz/blues/rock - jademaze.com music industry org - chatmusic.com
acoustic/funk/world-beat - astrakelly.com sculptures - olivierledoux.com
my own nascent company - l-i-e.com cool coffeehouse - uncommonground.com
Re: Using GPG in the US [ In reply to ]
On Mon, 23 Nov 1998, Caskey L. Dickson wrote:
> On Mon, 23 Nov 1998, Jimmy Kaplowitz wrote:
>
> > Thanks, Brian, and everyone else who responded to my questions. (I guess
> > that would be you, Casey :) The replies were very helpful. One further
> > question, though. What are the RSA and IDEA plugins, why can't I legally
> > use them in the US, and is there some legal way to get that
> > functionality with GPG in the US?
>
> I can't speak about IDEA, but RSA is patented in the US. That means that
> to use it you must have a license from the patent holders. Without that
[snip]

In re-reading that post, I realized that my comment re: the PTO may have
implied that I believed patents to be a solely US concoction, that is not
the case. Sorry for the confusion.

C=)

--------------------------------------------------------------------------
"Premature optimization is the root of all evil" -Donald Knuth
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: aiiieeeeeee!!!
--------------------------------------------------------------------------
If you want to build a ship, don't drum up people together to collect wood
and don't assign them tasks and work, but rather teach them to long for
the endless immensity of the sea. -- Antoine de Saint Exupery
Re: Using GPG in the US [ In reply to ]
%% "Caskey L. Dickson" <caskey@technocage.com> writes:

cld> I can't speak about IDEA, but RSA is patented in the US. That
cld> means that to use it you must have a license from the patent
cld> holders. Without that license, under US intellectual propertly
cld> laws you would be infringing upon the creator's (patent holder's)
cld> rights of sole exploitation of something they devised.

Well, but wait. I took a look at the RSAREF 2.0 library license back in
Sep. and as far as I can see, you can certainly legally use that for
non-commercial purposes (that is, no one is paying you money due to your
use of it) in the USA.

Here's what the license says (fom the doc/info.txt file):

WHAT YOU CAN (AND CANNOT) DO WITH RSAREF

1. RSAREF is free for personal or corporate use under the
following conditions:

o RSAREF, RSAREF applications, and services based on
RSAREF applications may not be sold.

o You must give RSA the source code of any free RSAREF
application you plan to distribute or deploy within
your company. RSA will make these applications
available to the public, free of charge.

[...]

RSA LABORATORIES RSAREF 2.0 PROGRAM LICENSE AGREEMENT

RSA LABORATORIES, A DIVISION OF RSA DATA SECURITY, INC. ("RSA")
GRANTS YOU A LICENSE AS FOLLOWS TO THE "RSAREF" PROGRAM:

1. LICENSE. RSA grants you a non-exclusive, non-transferable,
perpetual (subject to the conditions of Section 8) license for
the "RSAREF" program (the "Program") and its associated
documentation, subject to all of the following terms and
conditions:

a. to use the Program on any computer;

b. to make copies of the Program for back-up purposes;

c. to modify the Program in any manner for porting or
performance improvement purposes (subject to Section 2) or
to incorporate the Program into other computer programs for
your own personal or internal use, provided that you provide
RSA with a copy of any such modification or Application
Program by electronic mail, and grant RSA a perpetual,
royalty-free license to use and distribute such
modifications and Application Programs on the terms set
forth in this Agreement.

d. to copy and distribute the Program and Application Programs
in accordance with the limitations set forth in Section 2.

[...]

2. LIMITATIONS ON LICENSE.

[...]

b. The Program may not be used directly for revenue-generating
purposes. You may not:

(i) use the Program to provide services to others for which
you are compensated in any manner;

(ii) license or otherwise distribute any Application Program
in any manner that generates income to you, including
without limitation any income on account of license
fees, royalties, maintenance fees and upgrade fees; and

(iii) license or otherwise distribute any Application
Program without the express written acknowledgment of
the end user that the Program will not be used in
connection with any revenue-generating activity of the
end user.

Nothing in this paragraph prohibits you from using the
Program or any Application Program solely for internal
purposes on the premises of a business which is engaged in
revenue-generating activities.

FWIW.

--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
Re: Using GPG in the US [ In reply to ]
On Mon, Nov 23, 1998 at 02:56:01PM -0800, Caskey L. Dickson wrote:
> On Mon, 23 Nov 1998, Jimmy Kaplowitz wrote:
>
> > Thanks, Brian, and everyone else who responded to my questions. (I guess
> > that would be you, Casey :) The replies were very helpful. One further
> > question, though. What are the RSA and IDEA plugins, why can't I legally
> > use them in the US, and is there some legal way to get that
> > functionality with GPG in the US?
>
> I can't speak about IDEA, but RSA is patented in the US. That means that
> to use it you must have a license from the patent holders. Without that
> license, under US intellectual propertly laws you would be infringing upon
> the creator's (patent holder's) rights of sole exploitation of something
> they devised. In a short while (2 years?) the RSA patents will expire as
> well and then there will be no restriction upon use.

IDEA is likewise patented (and, worse, it's worldwide: it's really not
usable in any commercial setting without paying royalties, though
Ascom hints that they may license it for 'freeware' it's still not
proper in a GPL'd work, since it's unclear if Linux is 'freeware' if
you buy it on CD). You can use it 'for private purposes' freely
though. But since some of us effectively have no life (who, me?) and
most of their life is their job, it's not very useful to me.

> With software, the whole scheme gets screwed up. It effectively becomes a
> license to use software, without which you are infringing upon the owners
> right to decide who gets to use his ideas.

And the lifetime is insane for software. 17 years is 8-10 generations
of computer hardware. (Of course, copyrights on software are silly,
too, since author-lifetime+75/50 years is effectively forever.
You can't run Wordstar on your CP/M-80 emulator without a license...)

> As luck would have it, patents do expire (17years?) and cannot be renewed.

And as double luck would have it, RSA was patented too early. In less
than two years the RSA patents expire, which makes the choice of RSA or
ElGamal one of taste not legality. :) Of course, RSADSI has managed to
stymie a lot of electronic commerce in the meantime.

That said: you can use the IDEA plugin fine if you're not doing it for
work. The RSA plugin you normally could use for non-commercial
purposes.. but... the good folks at RSADSI insist that the only
implementation of RSA is in their 'RSAREF' and that's the only version
that gets the free license in the US.

So, it's technically a violation of patent law to use the RSA plugin
in the US, whether for commercial purposes or not.

The good news is that this legal mess has been a problem for PGP, too,
so the 'freeware' versions of PGP don't do RSA anymore and the newer
keys are quite happy getting along with GPG.

--
Brian Moore | "The Zen nature of a spammer resembles
Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
Usenet Vandal | is higher up on the evolutionary chain."
Netscum, Bane of Elves. Peter Olson, Delphi Postmaster
Re: Using GPG in the US [ In reply to ]
On Mon, Nov 23, 1998 at 05:11:55PM -0600, Richard Lynch wrote:
>
> At the risk of sounding like a jerk, the answer seems pretty clear:
>
> These are patented technologies. The holders of these patents can bring
> suit against people who use them without paying license fees. The only
> legal way to use them is to contact RSA (the company) and pay them big
> piles of money. I assume IDEA is similar, but am not familiar with IDEA.

Although RSADSI doesn't usually go after individuals, I wouldn't rule it
out. Stick with DH/DSS and wait for the RSA patent to expire. :)

IDEA's license is printed at the start of idea.c, available on the ftp
site. It's much more reasonable than RSA's (it doesn't tie you to using
their code, for example: RSA mandates using RSAREF) and implies it's
possible to get a license for 'freeware' if you ask nice:

Requests by freeware developers to obtain a royalty-free
license to spread an application program containing the
algorithm for non-commercial purposes must be directed to
Ascom.

Of course, patented code still sucks, but at least they're not as evil
as RSA. (Patent holder do have to enforce their patents to protect
them, but granting a 'free license' doesn't mandate giving up their
patent as non-enforcement would.)

--
Brian Moore | "The Zen nature of a spammer resembles
Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
Usenet Vandal | is higher up on the evolutionary chain."
Netscum, Bane of Elves. Peter Olson, Delphi Postmaster
Re: Using GPG in the US [ In reply to ]
On 23 Nov 1998, Paul D. Smith wrote:

> %% "Caskey L. Dickson" <caskey@technocage.com> writes:
>
> cld> I can't speak about IDEA, but RSA is patented in the US. That
> cld> means that to use it you must have a license from the patent
> cld> holders. Without that license, under US intellectual propertly
> cld> laws you would be infringing upon the creator's (patent holder's)
> cld> rights of sole exploitation of something they devised.
>
> Well, but wait. I took a look at the RSAREF 2.0 library license back in
> Sep. and as far as I can see, you can certainly legally use that for
> non-commercial purposes (that is, no one is paying you money due to your
> use of it) in the USA.

This is very true, however I do not believe that the RSA plugin was built
with RSAREF and therefore does not apply to the discussion as to what the
legal aspects of using the GnuPG RSA and IDEA plugins in the US are.

I'm sure if someone were to re-write the RSA plugin to use RSAREF then I'm
sure that everyone would be grateful. It doesn't get around the usage
issue for me personally because almost everything I do is related to my
job.

C=)

--------------------------------------------------------------------------
"Premature optimization is the root of all evil" -Donald Knuth
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: aiiieeeeeee!!!
--------------------------------------------------------------------------
If you want to build a ship, don't drum up people together to collect wood
and don't assign them tasks and work, but rather teach them to long for
the endless immensity of the sea. -- Antoine de Saint Exupery
Re: Using GPG in the US [ In reply to ]
On Mon, Nov 23, 1998 at 03:38:36PM -0800, brian moore <bem@cmc.net> wrote:
[...]
> That said: you can use the IDEA plugin fine if you're not doing it for
> work. The RSA plugin you normally could use for non-commercial
> purposes.. but... the good folks at RSADSI insist that the only
> implementation of RSA is in their 'RSAREF' and that's the only version
> that gets the free license in the US.

How hard would it be to wrap RSAREF to be compatible with GPG? Then
at RSA could be used for non-business things in the US right now.

-Daniel Eisenbud

--
Daniel Eisenbud
daniel@math.berkeley.edu
eisenbud@cs.swarthmore.edu (try this one if the Berkeley address bounces)
Re: Using GPG in the US [ In reply to ]
%% "Caskey L. Dickson" <caskey@technocage.com> writes:

cld> This is very true, however I do not believe that the RSA plugin
cld> was built with RSAREF and therefore does not apply to the
cld> discussion as to what the legal aspects of using the GnuPG RSA
cld> and IDEA plugins in the US are.

Certainly, but as you point out (and as I assumed but didn't state)
someone could rework the plugin to use rsaref. The code that _uses_
rsaref is distributable, it's just the rsaref code itself that isn't.
If someone developed an rsaref "shim" for the existing plugin, that
would be cool and distributable. Then the docs would just have to say
"in the US, go get rsaref from RSA, compile it, and point it out to
configure with --enable-rsaref." Or something :).

cld> It doesn't get around the usage issue for me personally because
cld> almost everything I do is related to my job.

I'm not so sure; go take another look at the details of the license. As
I read them, they're pretty liberal. It looks to me like as long as you
don't make money _directly_ from your use of RSA (like selling a program
or a service that uses RSA) you're fine.

For example, as I read it, there would be no problem signing email
messages associated with your job via an RSA algorithm.

Of course, IANAL.

--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
Re: Using GPG in the US [ In reply to ]
On 23 Nov 1998, Paul D. Smith wrote:

> %% "Caskey L. Dickson" <caskey@technocage.com> writes:
>
> cld> This is very true, however I do not believe that the RSA plugin
> cld> was built with RSAREF and therefore does not apply to the
> cld> discussion as to what the legal aspects of using the GnuPG RSA
> cld> and IDEA plugins in the US are.
>
> Certainly, but as you point out (and as I assumed but didn't state)
> someone could rework the plugin to use rsaref. The code that _uses_
> rsaref is distributable, it's just the rsaref code itself that isn't.
> If someone developed an rsaref "shim" for the existing plugin, that
> would be cool and distributable. Then the docs would just have to say
> "in the US, go get rsaref from RSA, compile it, and point it out to
> configure with --enable-rsaref." Or something :).

This may sound rude, but I'm not trying to be, I'm just tired: What
you've concluded is what is already known. If you want to make the shim,
do it and we'll benefit and be thankful when we can use it, otherwise
we've simply spent all this time and energy to established facts that we
all knew beforehand. (I don't know about you but that makes me feel like
I've not only wasted my time but also the time of everyone else on this
list--I don't like to feel that way.)

One of my favorite things about OSS is that nobody ever has a (valid)
reason to complain about how something works. If you don't like the way
something works, modify it or get off the bus.

> cld> It doesn't get around the usage issue for me personally because
> cld> almost everything I do is related to my job.
>
> I'm not so sure; go take another look at the details of the license. As
> I read them, they're pretty liberal. It looks to me like as long as you
> don't make money _directly_ from your use of RSA (like selling a program
> or a service that uses RSA) you're fine.
>
> For example, as I read it, there would be no problem signing email
> messages associated with your job via an RSA algorithm.

As far as signing messages: "plausable deniability". Anything I sign
would be commercial in nature, or a bit of GnuWare, in which case I'd just
use GnuPG and RSA is moot.

Communiating with clients and staff using messages encrypted via RSAREF in
the course of pursuing my business clearly violates the license and places
my business in the very ugly position of violating the rights of a much,
much bigger company. Nobody in their right mind who has everything
invested in their business would do such a thing. At least not for very
long. :-)

As for your determination that so long as you are not directly profiting
from it you are not violating the license--you said it yourself: YANAL.
Neither am I but I do have a business that I'd like to keep and so the
benefits are essentially nonexistent to use RSAREF.

C=)

--------------------------------------------------------------------------
"Premature optimization is the root of all evil" -Donald Knuth
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: aiiieeeeeee!!!
--------------------------------------------------------------------------
If you want to build a ship, don't drum up people together to collect wood
and don't assign them tasks and work, but rather teach them to long for
the endless immensity of the sea. -- Antoine de Saint Exupery
Re: Using GPG in the US [ In reply to ]
%% "Caskey L. Dickson" <caskey@technocage.com> writes:

cld> On 23 Nov 1998, Paul D. Smith wrote:
>> %% "Caskey L. Dickson" <caskey@technocage.com> writes:

cld> This is very true, however I do not believe that the RSA plugin
cld> was built with RSAREF and therefore does not apply to the
cld> discussion as to what the legal aspects of using the GnuPG RSA
cld> and IDEA plugins in the US are.

>> Certainly, but as you point out (and as I assumed but didn't state)
>> someone could rework the plugin to use rsaref.

cld> This may sound rude, but I'm not trying to be, I'm just tired:
cld> What you've concluded is what is already known. If you want to
cld> make the shim, do it and we'll benefit and be thankful when we
cld> can use it, otherwise we've simply spent all this time and energy
cld> to established facts that we all knew beforehand. (I don't know
cld> about you but that makes me feel like I've not only wasted my
cld> time but also the time of everyone else on this list--I don't
cld> like to feel that way.)

This may also sound rude, and I'm not trying to be either, but it
doesn't bother me that you feel that way.

It was obvious to me by the questions that started this thread and the
comments made on it so far that not _everyone_ knew this. Otherwise I
wouldn't have posted. Statements were being made about RSA, in general,
being patented and not available for use in the US without $$ for
licensing, not about the gpg RSA plugin in particular. Furthermore,
even people who know about RSAREF may not have checked the licensing
lately: I understand earlier versions were significantly more
restrictive.

If such a thing were available _I'd_ certainly use it, to implement
PGP-verification on my USENET INN server. They are still signing with
PGP-2 so I have no alternatives. And that clearly falls within the
RSAREF license.

cld> One of my favorite things about OSS is that nobody ever has a
cld> (valid) reason to complain about how something works. If you
cld> don't like the way something works, modify it or get off the bus.

Please don't pull out that hoary old chestnut. Even people dedicating
their entire lives to OSS, like RMS, don't have enough time to do
everything. Just because the source is open doesn't mean that anyone
who won't or can't do the work themselves has no right to make
suggestions.

I do plenty for OSS, myself, and I feel no guilt about not jumping right
into this project, too.

cld> Communiating with clients and staff using messages encrypted via
cld> RSAREF in the course of pursuing my business clearly violates the
cld> license and places my business in the very ugly position of
cld> violating the rights of a much, much bigger company. Nobody in
cld> their right mind who has everything invested in their business
cld> would do such a thing. At least not for very long. :-)

I think you're wrong about "clearly violat[ing] the license". The only
questionable part is section 2.b.i. The issue is whether or not, in the
above cases, you are being compensated for using the rsaref-derived
program. I'd say obviously not; you're being compensated for the
contents of the messages and documents, not for encrypting them. YM, of
course, MV.

Anyway, it's not my intent to convince people to use rsaref if they're
uncomfortable with it. I'm merely pointing out that it's there, it
_could_ be used, if someone put some (probably small amount of) work
into it, and its license is undeniably quite suitable for many uses:
exactly which is up to you or your lawyer's interpretation, as with all
licenses, obviously.

'Nuff said. Bye.

--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
Re: Using GPG in the US [ In reply to ]
RSA system is patented in US (#4,405,829) by Public Key Partners. You can
license RSA for usage (commercial or non-commercial) from RSA Data
Security (RSADSI www.rsa.com) as part of their various toolkits. RSAREF is
only available for non-commercial usage (they dropped licensing of it for
commercial usage ~1996).

IDEA block cipher is patented in US (#5,214,703) by Ascom Tech AG and is
also patented in Europe (#0482154), and Japan. For licensing details see:
<http://www.ascom.ch/infosec/idea/licensing.html>.

DES is/was patented by IBM in US but allowed for free usage, as part of an
agreement with NBS/ NIST in accepting it as a NIST standard, AFAIK.

From RSAREF 2.0 doc/license.txt
...
b. The Program may not be used directly for revenue-generating
purposes. You may not:

(i) use the Program to provide services to others for which
you are compensated in any manner;
...

From RSAREF 1.0 README
"You can't use RSAREF in any commercial (moneymaking) manner of any type,
nor can you use it to provide services of any kind to any other party."

IANAL but it would prevent the usage of GPG w/RSA from being use "on the
job" for services such as USENET newsfeed (a service for paying customers),
or encrypting business email (your work is the service you are compensated
for). You could use it for your office hockey pool. :)

Thus RSA support with or without using RSAREF cannot be official supported
as part of a GNU package since the license and patant restrictions prevent
it from meeting the requirements of the GNU Public License 2.0.

Since all this goes against the GNU ideology, those who need PGP w/RSA
support should consider licensing PGP 2.6.x or PGP 6.x from Network
Associates or Network Associates International BV. Then just let the rest
of us get on with GnuPG and its development.

--
M Taylor mctaylor@ / glyphmetrics.ca | privacy.nb.ca
Re: Using GPG in the US [ In reply to ]
Thank you all so very much for answering my question. Now any time I
forget, or next time I need that script that Brian Moore demonstrated, I
can check the archive. By the way, I tried the script hand-typed,
changing "pgpkeys.mit.edu" to "certserver.pgp.com". It worked, seemingly
indicating that any server works, with the same port, path, etc. Also, I
am probably saying nothing new by mentioning this, but I at first
searched for a handle and got 3 matching keys, all of which were
imported into gpg. It is nice to know that gpg can handle simultaneous
importation of multiple keys. I only wanted one of those, but it is a
nice feature.

Again, my thanks to everybody who responded to my questions.

- Jimmy Kaplowitz
jkaplowitz@softhome.net
Re: Using GPG in the US [ In reply to ]
Jimmy Kaplowitz <jkaplowitz@softhome.net> writes:

> imported into gpg. It is nice to know that gpg can handle simultaneous
> importation of multiple keys. I only wanted one of those, but it is a

But be warned: GnuPG does currently not lock the trustdb or the
keyrings, so if two gpg processes run on the same files you loose.


Werner


p.s.

Yes, it is on my shortlist.
Re: Using GPG in the US [ In reply to ]
> Actually, I used to use PGP5 for that ('pgpk -a someone@somewhere') and
> then extract from PGP5 and into GPG... I realized how stupid that was,
> so did the one-line-script trick. :)

Yeah. I actually read (I think it was in the PGP5-GPG HOWTO!) something
whereby someone recommended that you use PGP itself to import keys into
GPG! That's where I got my misimpression that PGP was necessary for that
task. Shocking...

> You should be able to use any of the usual keyservers, since that's all
> that PGP5/6 does with the fancy gui under Windoze. I like my way
> better. :)

Me too :) Not least because it dispenses with the need for PGP at all.

> --
> Brian Moore | "The Zen nature of a spammer resembles
> Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
> Usenet Vandal | is higher up on the evolutionary chain."
> Netscum, Bane of Elves. Peter Olson, Delphi Postmaster

VERY cool signature :) BTW what kind(s) of Hacker/Vandal/Netscum are
you?

- Jimmy Kaplowitz
jkaplowitz@softhome.net
Re: Using GPG in the US [ In reply to ]
Aah. I never thought of running two gpg processes at once. I'm sure not
many people do, but it's good that you thought of it :) That means it
will probably be fixed soon. That is especially good when your box is
multi-user ... it is very rare for more than one person to use my box at
once. However, I doubt two people would be running gpg on the same
files, let alone simultaneously.

- Jimmy Kaplowitz
jkaplowitz@softhome.net

Werner Koch wrote:
> But be warned: GnuPG does currently not lock the trustdb or the
> keyrings, so if two gpg processes run on the same files you loose.
>
> Werner
>
> p.s.
>
> Yes, it is on my shortlist.
Re: Using GPG in the US [ In reply to ]
On Wed, Nov 25, 1998 at 03:21:46AM +0000, Jimmy Kaplowitz wrote:
> Aah. I never thought of running two gpg processes at once. I'm sure not
> many people do, but it's good that you thought of it :) That means it

A system using GPG as a back end in some sort of transaction processor
on the web could easily run into this situation.
--
David Hayes
david@hayes-family.org
Re: Using GPG in the US [ In reply to ]
>Werner Koch wrote:
>> But be warned: GnuPG does currently not lock the trustdb or the
>> keyrings, so if two gpg processes run on the same files you loose.

Yikes!!!

<HOPEFULLY>
Is this an issue only during the import/generation of keys?...
</HOPEFULLY>

I've been working toward a secure web-site using gpg to encrypt credit card
orders to e-mail to client as a low-volume free alternative to CyberCash et
al. I'd hate to have it not work if two people ordered at the same time...

One thing I'm still confused about:

If I generate a key, why is it not automatically assigned trust value 4,
and a calculated path to it set? Does one regularly generate a key for
themselves and not trust it?... It seems to me the default when you
generate a key should be f/? where ? is whatever goes there once a path is
found to the key...

-- "TANSTAAFL" Rich lynch@cognitivearts.com webmaster@ and www. all of:
R&B/jazz/blues/rock - jademaze.com music industry org - chatmusic.com
acoustic/funk/world-beat - astrakelly.com sculptures - olivierledoux.com
my own nascent company - l-i-e.com cool coffeehouse - uncommonground.com
Re: Using GPG in the US [ In reply to ]
On Wed, 25 Nov 1998, Jimmy Kaplowitz wrote:

> > Actually, I used to use PGP5 for that ('pgpk -a someone@somewhere') and
> > then extract from PGP5 and into GPG... I realized how stupid that was,
> > so did the one-line-script trick. :)
>
> Yeah. I actually read (I think it was in the PGP5-GPG HOWTO!) something
> whereby someone recommended that you use PGP itself to import keys into
> GPG! That's where I got my misimpression that PGP was necessary for that
> task. Shocking...

I guess that would be my fault. What has become called the PGP5-GPG howto
was originally written in the context of a former PGP5 user interested in
divesting themselves of PGP5 but maintaining their ability to communicate
with friends and family who still used PGP5. From that perspective,
already having pgpk and using it to retrieve the key made sense. In no way
did I mean to imply that it was a prerequisite.

I plan to update it a week or so to incorporate the added features since
v.0.4.0 that make the process easier. I'll be adding the methods of
fetching keys suggested by Brian Moore and a disclaimer to the pgpk
method to be sure that nobody is misled.

C=) "a.k.a. the Purveyor of Hoary Old Chestnuts"

--------------------------------------------------------------------------
Some say the glass is half full, others half empty; I say it is too big.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: aiiieeeeeee!!!
--------------------------------------------------------------------------
If you want to build a ship, don't drum up people together to collect wood
and don't assign them tasks and work, but rather teach them to long for
the endless immensity of the sea. -- Antoine de Saint Exupery
Re: Using GPG in the US [ In reply to ]
Richard Lynch <lynch@cognitivearts.com> writes:

> <HOPEFULLY>
> Is this an issue only during the import/generation of keys?...
> </HOPEFULLY>

And when you assign new trust values.

> If I generate a key, why is it not automatically assigned trust value 4,
> and a calculated path to it set? Does one regularly generate a key for

Hmmm, whats 4? If the secret key is available, the trust is always
assumed to be "ulimately trusted". I know that I fixed something like
this in the latest release.


Werner
Re: Using GPG in the US [ In reply to ]
I hope this doesn't get into a long discussion, but my opinion is that
M. Taylor's intepretation of the RSAREF license is incorrect:

On Nov 24, 2:28pm, M Taylor wrote:
> From RSAREF 2.0 doc/license.txt
> ...
> b. The Program may not be used directly for revenue-generating
> purposes. You may not:
>
> (i) use the Program to provide services to others for which
> you are compensated in any manner;
> ...
> IANAL but it would prevent the usage of GPG w/RSA from being use "on the
> job" for services such as USENET newsfeed (a service for paying customers),
> or encrypting business email (your work is the service you are compensated
> for). You could use it for your office hockey pool. :)

I do not think b. (i) applies to individuals being compensated for their
services to their employers, but only to companies being compensated for
services they supply. This opinion is based on the statement at the end
of section b. that says:

Nothing in this paragraph prohibits you from using the
Program or any Application Program solely for internal
purposes on the premises of a business which is engaged in
revenue-generating activities.

I don't think they would say that if they intended to exclude any use
for which one is paid by his or her employer.


> From RSAREF 1.0 README
> "You can't use RSAREF in any commercial (moneymaking) manner of any type,
> nor can you use it to provide services of any kind to any other party."

So don't use RSAREF 1.0. The RSAREF 2.0 license was deliberately made
to be more lenient so it could be used by corporations as long as they
didn't sell software that includes it or sell services that directly use it.


> Thus RSA support with or without using RSAREF cannot be official supported
> as part of a GNU package since the license and patant restrictions prevent
> it from meeting the requirements of the GNU Public License 2.0.
>
> Since all this goes against the GNU ideology, those who need PGP w/RSA
> support should consider licensing PGP 2.6.x or PGP 6.x from Network
> Associates or Network Associates International BV. Then just let the rest
> of us get on with GnuPG and its development.

I completely agree that RSAREF is against the GNU ideology and cannot be
officially supported by GnuPG; RSAREF is not open source software and the
patent excludes other free implementations. However, the RSAREF 2.0
license is liberal enough for those of us who work for corporations to use
if we aren't Open Source purists. Personally, I wholeheartedly support
open source software when I can, and I would love to switch completely to
GnuPG, but I can't because I still need compatibility with older PGP
signatures at least for a while. I would glady use an RSAREF 2.0 interface
to GnuPG to ease the transition. I took a quick look at it one day and
it didn't look trivial, so it hasn't made it to the top of my priority list
yet to do it myself. I'll have to stick with my licensed software from
Network Associates for now.

- Dave Dykstra <dwd@bell-labs.com>