Delivery-Date: Wed Jan 12 04:33:45 2000
Message-Id: <200001120930.BAA22616@toad.com>
To: "Michael H. Warfield" <mhw@wittsend.com>
cc: Richard Guy Briggs <rgb@conscoop.ottawa.on.ca>,
        Greg Simpson <gws@sweet.com>, netdev@oss.sgi.com, gnu@toad.com
Subject: Re: linux-ipsec: Re: current IPSEC/SKIP implementations? 
In-reply-to: <20000111205025.C10109@alcove.wittsend.com> 
Date:   Wed, 12 Jan 2000 01:30:19 -0800
From: John Gilmore <gnu@toad.com>
Sender: owner-netdev@oss.sgi.com

> 	This basically says that crypto source code which is unencumbered
> may be exported merely by notifying them of the URL (mailto URL's????)
> where it is available from.  No review, no approval, no license, no key
> length silliness, and no inherited encumberances.  :-)

Under these draft regs, things are a lot better, though they still
restrict Internet distribution in ways that they couldn't get away
with for books (e.g. requiring you to notify the gov't when you
publish one?!).  The court cases will proceed until they really do
make it compatible with the First Amendment.

In particular it's unclear whether mirror sites also have to mail in
their URLs or face prosecution.  And if you KNOW that a recipient is
in one of the seven verboten countries, e.g. Syria or Cuba, then you
are still in trouble.  And if you provide technical assistance to
someone outside the US, like answering questions on a mailing list,
that's still a crime under separate sections of the same regulations.

I still plan to run the Linux IPSEC project using the same old rules
(avoiding US contributions), at least for a few months, while we see
how things shake out.  However, the Linux kernel people are free
to pick up the code and do what they want with it, including putting
it into the main distribution.

We were at least hoping we could get the include file and misc
"patches" changes into the 2.4 distribution, so we could stop patching a
bunch of existing kernel files (making it possible to distribute IPSEC
as a module that can be separately compiled, and added to any kernel).

Also note that the current IPSEC code only does VPNs and requires 
manual configuration and debugging.  We're shooting for a version that
does automatic configuration, and automatically encrypts with
anybody else who's also running IPSEC, within the next few months.
(We call that a Real Private Network, not a Virtual Private Network.)
I'd rather not have a monster user base running the old manual stuff,
making it hard to move over to the right stuff.  This is a case where
the good may be an enemy of the best; the current stuff doesn't
scale, but the best stuff will scale to worldwide use.

> 	I won't post the whole $#@$#@ thing (since you can read it at the
> CDT site anyways) but for things like "Idea" and "RSA", which ARE encumbered
> by patents, similar clauses exist at 740.17(a)(5) which say basically the
> same thing.

Actually that other section is for published source code that you can't 
commercialize, like Sun's "Community Source License".  Copylefted
code, even if it includes patented algorithms, isn't covered.  We
think.  But this part of the regs is particularly unclear.

This brings up a separate issue, which kernel folks may not care about
since it isn't in kernel code.  The Pluto daemon that negotiates keys
for the kernel currently implements RSA as one of its options, since
it's the best technology, and is available for use everywhere other
than the US, as well as in all US Federal sites, and in any big
company that has a patent license.  That patent expires in October
2000; in the meantime, US folks will run a risk if they don't do
something special (like replace the RSA implementation with a
paid-for-or-otherwise-licensed one).  I think they're OK as long as
they don't use the optional RSA feature, but it will become required
for automatic configuration, once we have that working.

	John