[5679] in cryptography@c2.net mail archive
No liberalization for source code, API's
daemon@ATHENA.MIT.EDU (Greg Broiles)
Sun Sep 19 11:59:06 1999
Message-Id: <4.2.0.58.19990918234445.00be2140@mail.wenet.net>
Date: Sat, 18 Sep 1999 23:55:40 -0700
To: cryptography@c2.net, cypherpunks@cyberpass.net
From: Greg Broiles <gbroiles@netbox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
There's been some discussion of this in the press, but not much discussion
of the specifics. BXA has published a "question-and-answer" document
discussing the anticipated regulations; it's available at
<http://www.bxa.doc.gov/Encryption/q&a99.htm>, and John Young has archived
a copy at <http://cryptome.org/bxa091699.htm>.
In particular, the aspects of the crypto export policy most directly
related to research, development, and discussion of improving security are
unchanged. In the BXA's words -
>Can you provide a few examples where a license will still be required?
>
>Licenses will still be required for exports of encryption technology,
>technical assistance, cryptographic application programming interfaces
>(CAPIs), source code and exports destined to foreign government and military
>end users.
and
>Is source code allowed to be exported under a license exception or does this
>policy only authorize the export of encryption object code?
>
>Source code will continue to be reviewed under a case-by-case basis. This
>update will allow the global export of object code encryption software under
>a license exception.
Also, their thinking about API's seems to have become more nuanced; they
now envision two classes of API's which are treated differently for export
purposes, to wit -
>How does the update to encryption policy affect the export of
>cryptographic application programming interfaces (CAPIs)?
>
>Cryptographic interfaces are divided into two classes: Open Cryptographic
>Interfaces (OCI) andClosed Cryptographic Interfaces (CCI). OCI's are
>considered crypto-with-a-hole because they permit a customer or other party
>to insert cryptography into an encryption item. OCI's will continue to be
>reviewed on a case-by-case basis through the licensing process.
>
>CCI's contain a mechanism (such as a digital signing key) that prevents a
>customer or other party from inserting cryptography into an encryption item.
>After a technical review of the binding mechanism, these products will be
>eligible for export under a license exception. If destined to a commercial
>enduser, the additional signing can take place under a license exception
>after a technical review. If destined to a foreign government or military
>entity, the additional signing requires a license.
>
>We intend to discuss this issue with industry as we consult on the
>implementation of this regulation.
.. so don't throw away those license forms yet, open source fans. The BXA
can now focus its efforts on Linux fans instead of Microsoft and Netscape/AOL.
--
Greg Broiles
gbroiles@netbox.com
PGP: 0x26E4488C
