David Moffatt wrote:
> Forgive my ignorance (I am newbie) but what exactly are you talking about?
One discussion of the issue as it affects a Linux component is:
http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/exportlaws.html
This is not entirely up to date and the author (me) is neither a lawyer nor
unbiased. It has lots of links, though, including links to stuff by
lawyers and people with very different biases.
> You can have CRYPTO APIs supported by the OS with external plug ins to do
> the actual work.
My understanding is that all that is controlled. A "crypto-shaped hole" for
plugins is subject to the same export restrictions as the crypto code itself...
> You then can ship different plugins to different places.
> Example HP-UX and others use something called CDSA. You can have crypto
> libraries ship with the OS
> something like the libraries RSA ships. You can even have extra system calls
> for encryption.
... and so are the libraries.
> The next question is what bit of code do you want to make hard to
> distribute.
> The user code? the entire OS? just one or two shared libraries? Remember
> the problem is not just the US laws. It is the French laws, The Russian
> laws, etc...
> (Until recently the French even kept out 56 bit DES)
>
> So the question boils down to: What is the end goal?
The problem is that tools that should be in every Linux distribution
currently aren't.
Last I looked, you needed to go to kerneli.org for international patches
if you wanted an encrypting file system. The kernel parts of FreeS/WAN
IPSEC are also patches. These could not be in the standard Linux kernel
because that is distributed from the US.
Neither those patches nor user-level crypto tools like SHH, PGP, the
SHTTP support for Apache, ... can be shipped with US-based Linux
distributions such as Redhat, unless Redhat either produce a crippled
export version or get an export license.
e.g I know of three distributions that ship with FreeS/WAN: Corel from
Canada, Conectiva from Brazil, and SuSE from Germany.
There are two related goals here. Get the kernel parts of these tools
into the standard Linux kernel and get the rest into US-based Linux
distributions.
> -----Original Message-----
> From: Cindy Cohn [mailto:Cindy@McGlashan.com]
> Sent: Tuesday, August 01, 2000 5:30 PM
> To: linux-kernel@vger.rutgers.edu; mozilla-crypto@mozilla.org
> Subject: Crypto
>
> Hello Linux kernal and Mozilla lists,
>
> Sorry for the cross posting, but I have been asked by members of both lists
> whether now would be a good time to add cryptography to open source
> programs and urged to post my reply to the list. As some of you may know,
> I served as the lead attorney in the Bernstein case challenging the
> government's regulation of encryption technology.
For details see http://www.eff.org/bernstein/
I'll try a summary. The EFF and Berstein argued that crypto export
restrictions, applied to source code, violate the constitutional protection
on freedom of speech. Two courts so far have agreed, the one first hearing
the case and the Ninth Circuit court on appeal.
Having lost twice, the gov't. changed the laws (or just the regulations?)
and asked to have the case re-heard.
> Although the regulations as issued in January (and the modifications
> proposed recently by BXA) are still overly complex and problematic, they do
> provide some real opportunities to include strong cryptography in public,
> nonprofit open source projects.
So the open questions are to what extent these changes allow us to
include crypto in kernel tarballs and US-based Linux distributions.
As I recall, someone from kernel.org said a few months back that
their lawyers were looking at this. Anyone know the results?
> If any of you would be interested in pursuing the question further, I'd be
> happy to discuss it. Please feel free to drop me an e-mail or give me a
> call.
>
> Cindy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:09 EST