First thoughts on new encryption regulations (fwd)

[Brian Behlendorf <br...@collab.net>]

Forwarded with permission.  Clearly, don't consider this gospel yet; a lot
still needs to be sorted out.  But it appears to be All Good (tm).

	Brian



---------- Forwarded message ----------
Date: Thu, 13 Jan 2000 09:42:45 -0500
From: Frank Hecker <fr...@collab.net>
Subject: First thoughts on new encryption regulations

As I written previously, in my spare time I've been looking at the
proposed new U.S. regulations for export of encryption software, with an
eye toward how they might affect SourceXchange, Tigris, and other
Collab.Net projects. As it happens, the new regulations are just about
released; you can find the official Department of Commerce press release
at

http://204.193.246.62/public.nsf/docs/60D6B47456BB389F852568640078B6C0

and the submitted-for-approval draft of the new regulations at

http://www.cdt.org/crypto/admin/000110cryptoregs.shtml

Based on my review of the new regulations (and subject to the usual
disclaimers: IANAL, etc.), here's what I'm reasonably sure of to start
with:

1. It will be OK for U.S. developers or organizations to put open source
encryption source code up on the Internet for general download (whether
on a U.S. site or not). (This is a direct consequence of the new
language in 740,13(e) regarding "unrestricted encryption source code".)

2. It will be OK for U.S. developers or organizations to post open
source
encryption source code in a public Internet forum (e.g., newsgroup or
mailing list gated to newsgroup). (This is based on considering such
posting as a special case of 1 above.)

3. It's OK for U.S. developers to provide technical assistance relating
to such open source encryption source code in a public forum, with the
possible exceptions of a) assistance provided in response to a request
from someone from the "T7" nations (Iran, Iraq, etc.) and b) assistance
provided regarding the creation of binaries from that source code (see
below). (This is based on the existing language 
in 744.9 -- which was not revised -- which specifies that technical
assistance prohibitions do not apply when you're entitled to export the
encryption software relative to which assistance is being provided.)

4. In practical terms there appear to be no major issues for non-U.S.
developers
who use U.S.-developed open source encryption source code in their own
open source products. Such products are in theory "subject to the EAR"
(because of the U.S. "content") but the EAR do not attempt to control
the products' distribution in any way.

The major thing I haven't quite got a full understanding of yet is
whether binaries created from open source encryption source code get any
special dispensations relative to encryption binaries in general. My
tentative conclusion is that they do not, and that export of "full
strength" (aka "128-bit") binaries created from open source encryption
source code (e.g., nightly builds, beta releases, final releases)
requires formal approval and review from BXA.

If that is true, then in addition I believe that

5. If an open source encryption product (in binary form) received
"retail" status from BXA (after formal BXA review and classification)
then its binaries (nightly builds, etc.) could be put up for general
download, except possibly with restrictions against download from "T7"
domains. (See 740.17(a)(3).)

6. If after BXA review and classification an open source encryption
product (in binary form) did _not_ receive retail status, then its
binaries could be put up for general download, except possibly with
restrictions against download from "T7" domains or "government domains".
(See 740.17(a)(2) and 734.2(b)(9)(ii).)

7. If an open source encryption product (in binary form) has an "open
cryptographic interface" then it is _not_ eligible for export as
described above, and you must apply to BXA for a real honest-to-goodness
export license. However this does not affect export of source code for
such a product. (Based on 740.17(f).)

To sum up, my tentative "rules for life in the new regime":

* Have no fear putting open source encryption source code up for
unrestricted download (as tarballs, CVS trees, whatever).

* Feel free to discuss such code in public forums, but go easy on email
and don't answer questions from Iranians, etc.

* Check with BXA on the issue of binaries.

Hope this is useful. For more on the reasoning behind the above see the
following in-progress draft documents:

http://www.hecker.org/writings/encryption-export-changes.html
http://www.hecker.org/writings/encryption-export-1999.html

(Note that these are based on the 12/17 draft regulations; the 1/10
regulations have some minor changes, but not enough to affect my
conclusions.)

Frank
-- 
Frank Hecker            work: http://www.collab.net/
frank@collab.net        home: http://www.hecker.org/