[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[frank@collab.net: Re: New encryption regulations]



I guess this could sched some light in the crypto discussion.

Regards,

	Joey

----- Forwarded message from Frank Hecker <frank@collab.net> -----

Mailing-List: contact fsb-help@crynwr.com; run by ezmlm
Date: Thu, 13 Jan 2000 10:31:42 -0500
From: Frank Hecker <frank@collab.net>
To: Ben_Tilly@trepp.com
CC: fsb@crynwr.com
Subject: Re: New encryption regulations

Ben_Tilly@trepp.com wrote:
> Take a look
> 
> http://www.cdt.org/crypto/admin/000110cryptoregs.shtml
> 
> Skip down to the words "open source".
> 
> "3. Also in §740.13, to, in part, take into account the "open source"
> approach to software development,
<snip>
> Looks good to me! :-)  Am I missing anything?

Yes. To start with, 740.13(e) applies only to source code. I don't see
anything in the regulations which gives special dispensations to
binaries generated from such code, so if you wanted to host compiled
binaries on your (U.S.) site  along with the source code, then I believe
you would have to formally apply to BXA and request classification of
your software; based on the results of that request you might be able to
export the binaries under the ENC license exception (e.g., using
740.17(a)(2) or 740.17(a)(3), depending on whether the products get
"retail" status or not). However you might have to implement access
controls on the binaries beyond what you have on the source code, for
example to prevent download requests from "government end-users" and the
"T7" nations (North Korea, Iran, Iraq, etc.)

If your source code implements an "open cryptographic interface" (e.g.,
something like the RSA PKCS#11 API) then your binaries are even more
tightly controlled, and it looks as if you might have to apply for a
formal export license (as opposed to using a license exception); see
740.15(f). (But again, this restriction does not apply to the source
code, just the binaries.)

Next, there's the issue of prohibitions against "technical assistance",
per 744.9. These prohibitions appear to be moot in the case of
assistance with source code, based on the language in 744.9(a) that says
it doesn't apply when you're already "entitled to export the encryption
commodities and software in question to the foreign person(s) receiving
the assistance."  However 744.9 appears to still apply in some cases
like where the person you're providing the assistance to is a national
of North Korea, etc.

(The new regulations don't give you any blanket exemption from
"knowingly exporting or reexporting" stuff to the "T7" nations;
740.13(e)(2) only gives you a specific "safe harbor" to put stuff up
for public download without triggering the "T7" prohibitions. However
that doesn't cover cases like export or assistance via email.)

Then there's the issue of combining U.S. and non-U.S. open source
encryption source code, both in the U.S. and elsewhere. Based on
740.17(d), "foreign products" including U.S. encryption source code
don't require BXA review or classification, and can be freely exported
from the U.S. However there still might be issues here due to language
elsewhere in the regulations. The prior regulations had some complicated
"de minimis" language which in effect made it illegal for non-U.S. code
imported into the U.S. to then be exported out again, even if the
non-U.S. code had no U.S. content at all, and I'm not sure yet if
vestiges of that might not be lurking somewhere.

740.17(d) also states that "foreign products" incorporating U.S. source
code are "subject to the EAR". This I'm sure will alarm some people
outside the U.S., but I don't know if this actually would cause any
problems in practice. It may be directed at persons under U.S.
jurisdiction, to alert them that they still have to follow U.S.
regulations when exporting such "foreign products"; it may also be
intended to give the U.S. government leverage over non-US persons or
companies who might export such products to "T7" nations.

So at least in my opinion the effect of the new regulations on FSBs is
not entirely straightforward, and I think we'll have to wait for further
public review of the regulations to see if some of this becomes clearer.

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

----- End forwarded message -----

-- 
GNU GPL: "The source will be with you... always."

Please always Cc to me when replying to me on the lists.


Reply to: