Overview of U.S. Encryption Export Regulations (1999)

Revision 0.5
Janury 9, 2000


This document provides an overview of current U.S. regulations controlling exports from the U.S. of encryption software, with a particular focus on how these regulations affect the ability of U.S. developers and businesses to participate in or sponsor development of open source encryption software.

Note: This document is for informational purposes only and is not intended as legal advice. If you wish to develop and distribute cryptographic software, particularly for commercial sale or distribution, then you should consult an attorney with expertise in the particular laws and regulations that apply in your jurisdiction.

This document discusses the U.S. export regulations in effect as of December 31, 1999. It does not address changes to those regulations which are promised to liberalize somewhat export of encryption software; I've addressed the potential effect of those promised changes in a separate document, "Analysis of Proposed Changes to U.S. Encryption Export Regulations".

Background on U.S. encryption export regulation

Before I discuss the details of the U.S. encryption export regulations themselves, it's worth briefly discussing the legal background to the regulations.

At the highest level the U.S. government regulates particular actions (e.g., "export") by particular people (e.g., U.S. citizens and residents) involving particular items (e.g., software of various types); those regulations are justified by various reasons and based on legislation passed by the U.S. Congress in the context of the U.S. Constitution. Traditionally most of the export regulations have been justified based on the need to protect national security and to support particular U.S. government policies toward other nations; thus, for example, the U.S. restricts export to almost all countries of certain nuclear power-related materials and technologies, in order to prevent proliferation of nuclear weapons, and restricts export of almost all items to certain countries deemed to support international terrorism, as part of U.S. sanctions and related policies directed against those countries. In the case of encryption software and technologies, one justification for regulation has been that encryption software and technology (and cryptography in general) have military applications.

Thus for a long time encryption export was covered by the International Traffic in Arms Regulations [ITAR], which cover "munitions" in general (guns, tanks, warplanes, etc.) and are administered by the Office of Defense Trade Controls [DTC], part of the U.S. Department of State [State]. The ITAR still exist, however they no longer regulate encryption export; in 1996 the Clinton Administration transferred regulation of export of encryption software, hardware, and technology from the ITAR to the Export Administration Regulations [EAR]. The EAR regulate "dual use" items, i.e., items which have both military and non-military uses, and are administered by the Bureau of Export Administration [BXA], part of the U.S. Department of Commerce [Commerce]. The EAR are part of the U.S. Code of Federal Regulations [CFR]; more specifically, they are in Title 15 of the CFR, "Commerce and Foreign Trade", Chapter VII, "Bureau of Export Administration, Department of Commerce (Parts 700-799)", Subchapter C, "Export Administration Regulations"; hence the EAR are also sometimes referred to as 15 CFR chapter VII subchapter C or 15 CFR Parts 730-774.

Like other U.S. government regulations, the EAR ultimately are authorized by laws passed by the U.S. Congress. The legal authority for the EAR rests principally on the Export Administration Act of 1979, as amended, and the International Emergency Economic Powers Act, as amended, as supplemented by various Presidential Executive Orders; for complete details see the document "Principal Statutory Authority for the Export Administration Regulations" [EARAuth].

The U.S. Constitution [Const], as interpreted by the U.S. Supreme Court, restricts which types of laws Congress may pass and what types of regulations the Executive branch may create and enforce. Thus, for example, the First Amendment to the Constitution [1stAm] prohibits Congress from restricting freedom of speech or of the press; based on this prohibition, and the U.S. Supreme Court's interpretations of it, it is difficult for Congress to legally restrict what people may say in public or write on paper and distribute. If encryption software (or software in general, for that matter) were to be designated by the Supreme Court as speech protected under the First Amendment then the question of export regulation of such software would not even come up, because Congress could not constitutionally pass legislation authorizing the Executive branch to make such regulations. However the Clinton Administration does not consider software to be constitutionally-protected speech, and although two lower courts have decided otherwise in the Bernstein case [Bernstein], in the absence of a Supreme Court decision the relevant legislation and regulations remain in general effect.

Outline of U.S. export regulations

The manner in which the U.S. government regulates export of encryption software can be quite confusing for those not previously familar with the actual regulations. It may be helpful therefore to give a general outline of how the regulations work. See also 15 CFR Parts 730, "General Information" [EAR730], and 732, "Steps for Using the EAR" [EAR732] for general information about the EAR and how they apply to particular export-related transactions.

Scope of the EAR

As noted in 15 CFR 730.3, at the highest level the EAR control the export of items considered to be "dual-use" items, i.e., to have both civilian and military uses. An "item" in the context of the EAR is not necessarily a physical object (like a computer) or a digital object (like a software product); as noted in 15 CFR Part 772, "Definitions" [EAR772], an "item" in the context of the EAR also could be a technology, i.e., the information necessary to produce particular physical or digital objects.

Also, as noted in 15 CFR 730.5, the EAR do not just regulate "exporting" in the conventional sense, i.e., sending something from the U.S. to a location outside the U.S. The EAR also regulate a number of related activities, including:

(15 CFR Part 734 [EAR734] discusses in more detail the various ways in which the EAR considers items, including technologies, to have been exported or reexported; see in particular 734.2(b).)

As I discuss below, this additional scope of the EAR very much complicates the task of developing open source encryption software in the U.S., since it means that developers can potentially violate the EAR even without actually transmitting any software outside the U.S.

Items subject or not subject to the EAR

Although the EAR potentially cover a very wide range of items and activities related to those items, not all of those items and activities are actually regulated by the EAR. As noted in 15 CFR Part 734 [EAR734], some items and activities are "subject to the EAR", i.e., fall under the scope of the regulations, and some are not. If an item and/or activity is not subject to the EAR then there are no EAR-specified regulations that apply to that item or activity.

However, being subject or not subject to the EAR does not in and of itself mean that particular items and activities are restricted or unrestricted respectively. Even items that are subject to the EAR may not require actual export licenses, as discussed below. On the other hand, items not subject to the EAR may still be regulated by other U.S. regulations, e.g., the ITAR or others.

As noted in 734.3(b)(3), among the items not subject to the EAR are "publicly available" technology and software, including technology and software that are "available for general distribution either for free or at a price that does not exceed the cost of reproduction and distribution" (from 734.7(a) and (b)). This provision means that most open source software is exempt from regulation under the EAR and, assuming it is not regulated under any other U.S. regulations (which is typically the case), U.S. developers can freely export such software from the U.S. and can participate in development of it with other developers around the world. However this is not the case for open source encryption software; encryption software is specifically excluded from the "publicly available" provisions, as discussed below.

Besides publicly available technology and software, other important items not subject to the EAR are printed materials, e.g., books, magazines, and newspapers, and related items (see 734.3(b)(2)). These of course are items which have traditionally been protected under the First Amendment; in this respect note that printed books containing encryption source code or descriptions of encryption technologies are not subject to the EAR, unlike encryption software and technology in other forms.

As noted in 734.3(c), the major class of items that are subject to the EAR is the list of items in the Commerce Control List (CCL) in 15 CFR Part 774 [EAR774]; this list of items subject to the EAR includes encryption software and technology, as I discuss below. Finally, as noted in 734.5(c) (and also discussed below), activities (as opposed to items) that are subject to the EAR include "technical assistance by U.S. persons relating to encryption commodities or software".

Prohibited activities

For those items and activities that are subject to the EAR (as previously discussed), the EAR define ten "general prohibitions" in 15 CFR 736 [EAR736] that relate to export, reexport, or related conduct. Typically this involves the EAR prohibiting certain exports, reexports, or activities unless you either obtain an export license or are able to take advantage of a specific exception to the licensing requirements.

As noted in 736.2(a), such general prohibitions may apply based on a variety of factors: what kind of item you're exporting or reexporting (e.g., how it is classified on the CCL), to what country or countries you're exporting or reexporting an item, for what ultimate end-user or end-use you're exporting or reexporting an item, or what other kind of conduct you're engaged in.

Note that the EAR general prohibitions (and associated licensing requirements) do not apply just to items created in the U.S. For example, while 736.2(b)(1) prohibits unauthorized export or reexport of EAR-controlled items of U.S. origin, 736.2(b)(2) goes on to prohibit unauthorized export or reexport of "foreign-made" items incorporating EAR-controlled items originating in the U.S., and 736.2(b)(3) adds a prohibition against unauthorized export or reexport of "foreign-produced direct products" of EAR-controlled technology or software originating in the U.S. Thus, for example, you might be prohibited from unauthorized export or reexport of a software product that was for the most part created outside the U.S. but which incorporates a software library created in the U.S. As discussed below, these types of prohibitions create major restrictions on what U.S. developers can do with respect to encryption software created outside the U.S.

The Commerce Control List

As noted in 15 CFR 738, "Commerce Control List Overview and the Country Chart" [EAR738], the Commerce Control List of export-controlled items covers ten categories of items, ranging from nuclear materials to space vehicles; within each category are found both export-controlled physical objects and export-controlled digital objects (software and "technology", i.e., information). As discussed below, encryption is covered under category 5, "Telecommunications and Information Security".

Each particular type of item placed on the CCL is assigned an Export Control Classification Number or ECCN based on its CCL category, as described in 738.2(d)(1), and given an entry in the CCL that describes (among other things) what type of items are included in that ECCN and for what reason(s) their export is controlled. There are twelve official "Reasons for Control", ranging from prevention of proliferation of nuclear weapons ("NP") to general reasons related to national security ("NS"); there is an "EI" Reason for Control applied just to encryption items. As noted in 738.2(d)(2)(i)(A), a particular item (i.e., listed in the CCL under a particular ECCN) may be controlled for multiple reasons; as discussed below, encryption software and technology are marked as being controlled not only under the special "EI" Reason for Control but also under the more general "NS" (national security) and "AT" (anti-terrorism) Reasons for Control.

The official Reasons for Control determine (among other things) which countries a particular item may be exported to without a license, based on a Country Chart included as Supplement No. 1 to Part 738 [EAR738S1]. Thus, for example, an item controlled for reasons of nuclear proliferation ("NP") might require a license to be exported to Armenia, but not to be exported to Australia or Austria. (The way in which the Country Chart works is slightly more complicated than that, since for a given Reason for Control there might be distinctions made that some items can be exported to more countries than others. Thus the Reason for Control in the CCL listing for a particular item will be supplemented by a reference to a particular column in the Country Chart, e.g., "NP Column 1" or "NP Column 2" as opposed to simply "NP"; in the case of the "NP" Reason for Control, an item controlled based on "NP Column 1" requires a license for export to most countries, but an item controlled based on "NP Column 2" requires an export license only for a few countries, including India, Israel, and Pakistan.) Note that the Country Chart does not include a column or columns for the "EI" (encryption item) Reason for Control; as discussed below, items controlled for "EI" reasons can be exported only to Canada without a license.

For more information on the Reasons for Control used in the Commerce Control List, see 15 CFR Part 742, "Control Policy - CCL Based Controls" [EAR742]; in particular, 742.15 describes the "EI" Reason for Control.

Export licenses and license exceptions

If an item is on the Commerce Control List then it's possible (depending on the Country Chart or provisions elsewhere in the EAR) that exporting that item to a particular country or set of countries requires special authorization, either in the form of an export license granted by the Bureau of Export Administration or in the form of a license exception granted by the EAR. If an export license is required then you must apply to BXA to request such a license, and may not export the item until and unless the license is approved; in many cases, especially those involving encryption, BXA will likely deny the request for a license as a matter of course. If you can make use of a license exception then you do not have to apply for a license; however you do need to provide notification to BXA of your use of the exception, and will also be required to keep certain records of your export-related activity.

(The license application process is described in 15 CFR Part 748, "Applications (Classification, Advisory, and License) and Documentation" [EAR748]. If you are not sure how a particular item is classified under the EAR - i.e., what its ECCN would be - or whether it is subject to the EAR at all, then you can ask the Bureau of Export Administration to advise you; see 748.3.)

15 CFR 740, "License Exceptions" [EAR740], describes the various license exceptions that are available. One of the most important license exceptions is "TSU" (for "Technology and Software - Unrestricted"); as noted in 740.13(d), the TSU license exception can be used to export most commercial proprietary shrink-wrapped software (e.g., a word processing or accounting package). The TSU exception cannot be used to export encryption software in general, but as discussed below there are ways in which some encryption software products can be exported using the TSU exception or other license exceptions created specifically for encryption software.

However note that the EAR impose some restrictions even for items exported under the TSU license exception; for example, "mass market" software cannot be exported to Cuba, Iran, Iraq, Libya, North Korea, Sudan, and Syria (the "T7" nations accused by the U.S. of sponsoring international terrorism) under the TSU exceptions; see Supplement No. 2 to 15 CFR Part 774, "General Technology and Software Notes" [EAR774S2].

Regulation of Encryption Items

Now that we've explored some of the structure and provisions of the Export Administration Regulations, it's time to look specifically at how the EAR regulate encryption software and technology, starting with exactly how and why a particular piece of software is considered to be encryption-related in the first place.

Definition of Encryption Items

We start with the formal definitions of "encryption software" and related terms as used in the EAR, as found in 15 CFR Part 772, "Definitions" [EAR772]. Note that Part 772 does not define the term "encryption" itself, but does define the related term "cryptography", as "[the] discipline that embodies principles, means and methods for the transformation of data in order to hide its information content, prevent its undetected modification or prevent its unauthorized use"; the same definition goes on to say that "[cryptography] is limited to the transformation of information using one or more 'secret parameters' (e.g., crypto variables) and/or associated key management. information" and that a "secret parameter" is "a constant or key kept from the knowledge of others or shared only within a group."

"Encryption software" is then defined by the EAR to be "[computer] programs that provide capability of encryption functions or confidentiality of information or information systems", with "encryption items" (the more general term) defined to be "encryption commodities, software, and technology that contain encryption features and are subject to the EAR". "Commodities" are physical objects ("commodity" is defined as "[any] article, material, or supply except technology and software") ,while "technology" is information ("technology" is defined as "information necessary for the 'development', 'production', or 'use' of a product").

Thus, for example, a C program implementing the DES symmetric encryption algorithm would be considered "encryption software" under the EAR, a smart card implementing DES would be considered an "encryption commodity", and a verbal or written description of how the DES algorithm works would be considered "encryption technology". This is because the DES algorithm by its nature "embodies principles, means and methods for the transformation of data in order to hide its information content" (i.e., it encrypts data), and uses a "key kept from the knowledge of others or shared only within a group" (i.e., the 56-bit DES key).

On the other hand, if a program does only general-purpose transformation of data (and in particular does not manipulate data "in order to hide its information content") and does not use "secret parameters", then presumably it would not be considered "encryption software" in the context of the EAR. Thus, for example, a C program that translates generic binary data to base-64 encoded format or vice versa, for example in the context of processing email message attachments, presumably would not be considered encryption software, because the transformation in question does not use any sort of secret parameters but simply translates information from one public format to another without hiding its content (to anyone familar with the respective formats). Similarly a verbal or written description of base-64 encoding and decoding would not be considered "encryption technology" in the context of the EAR.

There are two special cases with regard to the EAR definitions and whether a particular piece of software is considered encryption software or not. The first is the case of programs which do not implement encryption functions in their own code, but which provide an application programming interface (API) by which others may add encryption capabilities, e.g., by calling an external library. (This is sometimes referred to as "crypto with a hole", although a better term would be "a hole for crypto".) As discussed below, programs using such APIs are considered to be "encryption software" in the context of the EAR (i.e., when deciding whether export licenses are required or not). The justification is presumably that such APIs are specifically intended to enable "the transformation of data in order to hide its information content", especially when they incorporate the use of "secret parameter[s]" of some sort.

The second special case is that of software (or technology, or physical hardware) that implements "cryptography" in the sense of "transformation of data in order to ... prevent its undetected modification or prevent its unauthorized use" but does not perform "transformation of data in order to hide its information content", in other words, software that implements authentication and data integrity protection using cryptographic techniques (e.g., digital signatures), but does not use encryption to provide data confidentiality. As discussed below, it is at least in principle possible for such software not to be classified as an "encryption item" in the context of the EAR.

Public available encryption items and the EAR

As previously discussed, "publicly available" software and technology in general are specifically exempted from regulation by the EAR (see 15 CFR Part 734 [EAR734], in particular 734.3(b)(3)). Open source software in general meets the definition of "publicly available" and the associated requirements in Part 734: open source software itself (in either source or binary form) is "available for general distribution either for free or at a price that does not exceed the cost of reproduction and distribution" (734.7(b)), and information relating to such software is "generally accessible to the interested public" by being "published" in electronic form (734.7(a)). Thus open source software in general is not subject to the EAR and may be freely exported and reexported without restriction by the EAR, for example by uploading it to an FTP or web site outside the U.S., placing it on an FTP or web site in the U.S. for general download by anyone on the Internet, sending "tarballs" of the software as email attachments, mailing the software on CDs, and so on.

Similarly, the EAR place no restrictions on the export or reexport of information relating to general-purpose open source software, including design and architecture information, detailed documentation, instructions on building and modifying the software, and so on; such information can be disseminated to anyone in the world in any form. Finally, the EAR place no restrictions on activities that U.S. persons may engage in relating to general open source software: they may travel outside the U.S. to consult on such software, may provide training on such software to non-U.S. persons in the U.S., may support non-U.S. open source developers by contributions of money, and so on.

However the EAR state that "encryption items" do not in general qualify for "publicly available" status, and thus are in general subject to regulation by the EAR. In particular, 734.3(b)(3), the clause exempting publicly available software from EAR regulation, excludes "software controlled for EI [Encryption Item] reasons under ECCN 5D002 on the Commerce Control List"; as we discuss below, open source encryption software falls under this CCL classification. 734.7(c) repeats this more restrictive treatment of encryption software: "note that encryption software controlled under ECCN 5D002 for EI reasons on the Commerce Control List ... remains subject to the EAR even when publicly available."

The only general relaxation of the EAR's special treatment of encryption items is that publication of encryption source code in printed books is specifically called out as not subject to the EAR; however this is only reasonable given that print material enjoys special First Amendment protections. However the note to 734.3(b)(2) and 734.3(b)(3) specifies that "notwithstanding §734.3(b)(2) [which exempts printed material from regulation], encryption source code in electronic form or media (e.g., computer diskette or CD ROM) remains subject to the EAR".

EAR classification of encryption items

As noted above, encryption items are classified as part of the Commerce Control List under Category 5, "Telecommunications and Information Security"; the relevant entries for encryption software and related items are found in the Supplement No. 1 to Part 774, Category 5, Part 2, "Information Security" [EAR774C5P2]. The most relevant entries and Export Control Classification Numbers are as follows: Encryption hardware, software, and technology classified under ECCNs 5A002, 5D002, and 5E002 are listed as controlled for reasons "NS" (national security), "AT" (antiterrorism), and "EI" (encryption item); as previously noted, reasons "NS" and "AT" apply to many types of items controlled under the EAR, but the special "EI" Reason for Control is specifically applied to encryption software, hardware, and technology formerly regulated under the ITAR and transferred to the EAR in 1996. Many of the provisions in the EAR single out items controlled for EI reasons for special treatment, usually to impose additional restrictions that would not be in effect were the items to be controlled only for NS and/or AT reasons. (This is an important point, as we'll discuss in more detail below.)

The language of the entry for 5D002 repeats and enlarges upon two key points I've previously discussed: First, the EAR claims that encryption software is regulated for its "functional capacity" and not because of any "information value" it has; this in effect denies that encryption software can be considered in the same category as verbal and written material protected by the First Amendment. The same note goes on to specify that encryption software is considered to have the same status under the EAR as "a commodity included in 5A002", i.e., a hardware encryption module; in other words, encryption functionality is regulated in the same manner whether implemented in hardware or software. Second, the note following specifies that "[encryption] software controlled for EI reasons under this entry remains subject to the EAR even when made publicly available", unlike other publicly available software which is explicitly exempted from regulation under the EAR. This repeats similar language in 743.7(c).

The language of the entries for 5D002 and 5A002 also apply to two of the issues previously discussed, namely the treatment of programs using encryption APIs but not having any actual encryption code, and the treatment of programs implementing cryptographic techniques but not for the purpose of encrypting arbirtrary data. First, according to paragraph 5D002.a, among the items controlled under ECCN 5D002 is "'Software' specially designed or modified for the 'development', 'production' or 'use' of equipment or 'software' controlled by 5A002, 5B002 or 5D002." A software library implementing encryption is an example of "software" controlled by 5D002 (based on paragraphs 5D002.b and 5D002.c), so presumably a program which is "specially designed or modified" for the "use" of such a library, i.e., by having code to call encryption-related APIs, is also controlled under 5D002 by virtue of paragraph 5D002.a, even if the software contains no actual encryption code itself.

For example, the PKCS#11 API [PKCS11] (defined by RSA Security, Inc. [RSASec]) is designed to enable programs to call encryption routines located in a separate library; such an external library implementing encryption functionality would be considered "encryption software" in the context of the EAR. A program incorporating code to call a PKCS#11-compliant external library would be considered "specially designed or modified" for the "use" of "encryption software", and thus itself would be considered "encryption software" in the context of the EAR, even if the program itself did not implement any encryption functionality. On the other hand, if a program called routines through APIs that were general-purpose in nature and not specifically associated with encryption, then presumably the program would not be considered "encryption software" in the context of the EAR, even if some of the external libraries it was capable of calling happened to implement encryption functionality.

Second, paragraph 5A002.a.1 specifies that equipment that is "[d]esigned or modified to use 'cryptography' employing digital techniques to ensure 'information security'" is controlled under 5A002. However earlier language in the entry under "Related Controls" exempts a number of classes of equipment from control, and in particular paragraph (h) under "Related Controls" exempts "[data] authentication equipment that calculates a Message Authentication Code (MAC) or similar result to ensure no alteration of text has taken place, or to authenticate users, but does not allow for encryption of data, text or other media other than that needed for the authentication." In other words, equipment is not controlled under 5A002 if it uses cryptographic techniques like encryption and digital signing solely to provide authentication and data integrity functions. Turning to ECCN 5D0002, under "Related Controls" in that entry the EAR states that "This entry does not control ... 'software' providing any of the functions of equipment excluded from control under 5A002." Thus if equipment providing only data integrity and authentication functions is not controlled under 5A002 as encryption hardware, then presumably software providing only those same functions is not controlled under 5D002 as encryption software.

License exceptions available for encryption software

As discussed above, as a general rule encryption software will be classified under ECCN 5D002 in the Commerce Control List, and will be subject to the restrictions associated with the EI Reason for Control. As I discuss in this section, there are some specific ways in which particular encryption software products may qualify for less restrictive treatment under the EAR.

As stated in the entry for 5D002 under "License Exceptions", there are no applicable license exceptions that may be used for encryption software in general; however the immediately previous note (under "License Requirements") states that "After a technical review, certain encryption software may be released from EI controls and made eligible for the General Software Note treatment as well as other provisions of the EAR applicable to software." The note goes on to give references to Part 742.15(b)(1) and Supplement No. 6 to Part 742, "Guidelines for Submitting a Classification Request for a Mass Market Software Product that Contains Encryption" [EAR742S6]; the "General Software Note treatment" referred to is discussed in Supplement No. 2 to Part 774, ""General Technology and Software Notes" [EAR774S2].

742.15 provides justifications for the EI Reason for Control and specifies licensing requirements for encryption items in general. 742.15(b)(1) in particular specifies a procedure by which one can apply to the Bureau of Export Administration to have an encryption software product released from EI controls, provided that the software implements encryption with a maximum key length of 56 bits. (More precisely, the product is limited to 56 bits for symmetric keys, e.g., DES keys, and 1024 bits for asymmetric keys, e.g., a 1024-bit modulus for RSA public/private key pairs.) If such "56-bit software" is considered to be "mass market" software (which would be the case for typical shrinkwrapped software intended for consumer use), then (after a technical review) BXA will likely approve it to be treated like other "mass market" software and make use of the TSU ("Technology and Software - Unrestricted") license exception discussed above. (Supplement No. 6 to Part 742 contains an exact definition of "mass market software", as well as detailed information on how to qualify for this less restrictive treatment.) This particular provision in the EAR is what allows "56-bit" versions of such software as Netscape Communicator and Microsoft Internet Explorer to be made available for unrestricted download over the Internet. (Mass market treatment and the use of the TSU license exception used to be restricted to "40-bit" versions of software; the maximum allowed key length was then later increased to 56 bits.)

"56-bit" encryption software that is not "mass market" software (for example, a complex product sold to enterprises and requiring extensive installation and integration support) is not eligible for the TSU license exception, but is eligible for a separate ENC license exception; again, this requires BXA to do a technical review of the software and approve releasing it from EI controls. For more information see 742.15(b)(1)(iii) and 740.17(a)(3).

As noted in 740.17 (which describes the ENC license exception), the ENC license exception can also be used to export encryption software in a variety of other circumstances:

Note that all of these cases require technical review and approval by BXA, all impose some restrictions on the countries to which software can be exported, and some require reporting exports to BXA.

There is one more license exception applicable to encryption software: the KMI ("Key Management Infrastructure") license exception described in 740.8. The KMI license exception is available for encryption products that implement key recovery as described in Supplement No. 4 to Part 742, "Key Escrow or Key Recovery Products Criteria" [EAR742]. This license applies to software implementing Clipper-style mandatory key escrow features; as noted in paragraph (1) of Supplement No. No. 4 to Part 742, "[the] product's cryptographic functions shall be inoperable until the key(s) or other material/information required to decrypt ciphertext is recoverable by government officials under proper legal authority and without the cooperation or knowledge of the user."
Products using the KMI license exception can be exported to all countries except the "T7" nations.

Note that all the license exceptions available for encryption software - TSU, ENC, and KMI - require that the software be distributed in binary form. After all, these license exceptions require that the key length be limited (for TSU or ENC exceptions) or that the key escrow mechanism not be disabled (for KMI exceptions), and this would not be possible at all if the software were distributed in source form.

Thus any encryption software distributed in source form, including open source encryption software, will be classified in the CCL under ECCN 5D00, will remain subject to EI control, and will require a license for export to any country except Canada. Since such a license will not be granted except under very special circumstances, this essentially means that there is no legal way to export encryption source code from the U.S. in electronic form. (As previously discussed, encryption source code in printed form is not subject to the EAR and can be exported freely.)
However even this does not exhaust the restrictions imposed on encryption source code and open source encryption software, as discussed below.

Prohibitions relating to encryption items

To be written.


To be written.


First Amendment to the U.S. Constitution, <URL:http://www.law.cornell.edu/constitution/constitution.billofrights.html#amendmenti>
<URL: http://www.eff.org/pub/Legal/Cases/Bernstein_v_DoS/>
Bureau of Export Administration, <URL:http://www.bxa.doc.gov/>
Code of Federal Regulations, <URL:http://www.access.gpo.gov/nara/about-cfr.html>
U.S. Department of Commerce, <URL:http://www.doc.gov/>
U.S. Constitution, <URL:http://www.law.cornell.edu/constitution/constitution.overview.html>
Office of Defense Trade Controls, <URL:http://www.pmdtc.org/>
Export Administration Regulations (15 CFR Parts 730-774), <URL:http://w3.access.gpo.gov/bxa/ear/ear_data.html>
"Principal Statutory Authority for the Export Administration Regulations", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:lagauth.pdf>
EAR Part 730 (15 CFR Part 730), "General Information", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:730.pdf>
EAR Part 732 (15 CFR Part 732), "Steps for Using the EAR", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:732.pdf>
EAR Part 734 (15 CFR Part 734), "Scope of the Export Administration Regulations", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:734.pdf>
EAR Part 736 (15 CFR Part 736), "General Prohibitions", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:736.pdf>
EAR Part 738 (15 CFR Part 738), "Commerce Control List Overview and the Country Chart", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:738.pdf>
EAR Supplement No. 1 to Part 738, "Commerce Control List Overview and the Country Chart", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:738spir.pdf>
EAR Part 740 (15 CFR Part 740), "License Exceptions", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:740.pdf>
EAR Part 742 (15 CFRPart 742), "Control Policy - CCL Based Controls", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:742.pdf>
EAR Part 744 (15 CFR Part 744), "Control Policy: End-User and End-Use Based", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:744.pdf>
EAR Part 772 (15 CFR Part 772), "Definitions", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:772.pdf>
EAR Part 774 (15 CFR Part 774), "The Commerce Control List", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:774.pdf>
EAR Supplement No. 1 to Part 774, "Commerce Control List", Category 5, "Telecommunications and Information Security", Part 2, "Information Security", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:ccl5-pt2.pdf>
EAR Supplement No. 2 to Part 774, "General Technology and Software Notes", <URL:http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=bxa&docid=f:774_sup2.pdf>
International Traffic in Arms Regulations, <URL:http://www.pmdtc.org/itar2.htm>
PKCS#11, "Cryptographic Token Interface Standard", <URL:http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html>
RSA Security, Inc., <URL:http://www.rsasecurity.com/>
U.S. Department of State, <URL:http://www.state.gov/>

Frank Hecker