Analysis of Proposed Changes to U.S. Encryption Export Regulations

Revision 0.5
Janury 9, 2000


This document analyzes the changes which the Clinton administration has proposed for the U.S. regulations controlling exports from the U.S. of encryption software, with a particular focus on how these proposed changes would affect the ability of U.S. developers and businesses to participate in or sponsor world-wide 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 proposed changes released on December 17, 1999, by the U.S. Department of Commerce [Commerce] in the document "Draft II Encryption Export Regulations" [DraftII]. The changes need to be read in relation to the existing Export Administration Regulations [EAR] administered by the Bureau of Export Administration [BXA], and this document assumes that you have a basic knowledge of how the existing regulations are structured. For those unfamilar with the details of U.S. encryption export control I've provided an overview to the existing regulations in a separate document, "Overview of U.S. Encryption Export Regulations (1999)".

Summary of proposed changes and their effect

To be written.

Where changes were made

The Draft II document contains changes to the following parts of the EAR, with changes to individual sections and paragraphs as indicated: Note that the material in the Draft II document for ECCN entries 5B002 and 5E002 appears to be identical to that in the current EAR, and the material for those entries in the Draft II document constitutes only a part of a complete entry. I'm not sure why this is.

Detailed Analysis

The following sections contain a detailed analysis of the proposed changes.

New Definitions

The proposed changes to 15 CFR Part 772, "Definitions" [EAR772], add new definitions for five terms; no existing definitions were changed. Of the new definitions, the most relevant to our purpose are those for the terms "encryption component" and "open cryptographic interface".

An "encryption component" is defined to be "[any] encryption commodity or software (except source code), including encryption chips, integrated circuits, application specific encryption toolkits, or executable or linkable modules which alone are incapable of performing complete cryptographic functions, and is designed or intended for use in or the production of another encryption item." The grammar of this sentence is somewhat unclear due to ambiguity over where the clause "including encryption chips ..." ends. I presume the intended meaning is that an "encryption component" is "[any] encryption commodity or software (except source code) [which] is designed or intended for use in or the production of another encryption item", with examples of "encryption components" being given as "encryption chips, integrated circuits, application specific encryption toolkits, or executable or linkable modules which alone are incapable of performing complete cryptographic functions". (In other words, the correct reading of the definition is that obtained by replacing "and is designed ..." by "which is designed ...".)

The term "encryption component" is referenced extensively in the proposed changes to 740.17 and 742.15, as well as in Note 1 to Category 5, Part 2 of the Commerce Control List.

An "open cryptographic interface" is defined to be "[a] mechanism which is designed to allow a customer or other party to insert cryptographic functionality without the intervention, help or assistance of the manufacturer or its agents, e.g., manufacturer's signing of cryptographic code or proprietary interfaces." The definition that goes on to say that "If the programmatic interface to the cryptographic hardware or object code software has a fixed set of cryptographic algorithms, key lengths or key exchange management systems that cannot be changed, it will not be considered an "open" cryptographic interface." An open cryptographic interface is also distinguished from a "general application programming interface", where such interfaces are defined as "those that accept either a cryptographic or non-cryptographic interface but do not themselves maintain any cryptographic functionality".

This new definition clarifies an ambiguity in the existing regulations with regard to applications that implement an interface to encryption functionality, but do not themselves contain such functionality. Note that the new definition provides three ways in which an application can escape being classified as having an "open cryptographic interface": the interface can be general-purpose in nature, can implement only a fixed type of encryption functionality, or can control the type of functionality callable through the interface, for example, by requiring the add-on encryption modules be digitally signed by the application's developer (as done by Microsoft in the CryptoAPI scheme). However only the first of these ways applies to applications distributed as source code.

Open source encryption software in source form

In the existing regulations software in general is not "subject to the EAR" (its export is not regulated) when it is "publicly available"; software released as "open source" software (according to the Open Source Definition [OSD]) meets the EAR's criteria being "publicly available". However under the existing regulations encryption software is considered "subject to the EAR" (i.e., under regulation) even when it meets the criteria for being publicly available. (See 734.3(b)(3) and 734.7(a) through (c).) Also recall (from the definition of "open cryptographic interface" discussed above) that based on the proposed changes software in source code form will be considered to be encryption software if it provides an interface by which encryption functionality can be invoked, unless that interface is general-purpose in nature.

The simplest and most straightforward way for the U.S. government to relax controls on open source encryption software would have been to revise 734.3 and 734.7 to treat publicly available encryption software and technology in the same manner as other publicly available software and technology. However the proposed changes to the EAR do not do this. Instead the changes create a new class of "unrestricted encryption source code" which is released from EI ("Encryption Item") controls and may be exported and reexported under the TSU ("Technology and Software - Unrestricted") license exception. More specifically, the proposed language for 740.13(e) allows the TSU license exception to be used for "[encryption] source code controlled under
5D002 which would be considered publicly available under Section 734.3(b)(3) and which is not subject to an express agreement for the payment of a licensing fee or royalty for further commercial production or sale of any product developed from the source code" (740.13(e)(1)). Note that open source software meets these criteria, but that software in source form available under other licenses may not; for example, software released under the Sun Community Source License (SCSL) does not meet these criteria, because the SCSL requires payment of royalties for commercial derivative works.

The proposed new language for 740.13(e)(1) requires that those wishing to export encryption source code of this type must first submit written notification to the Bureau of Export Administration and provide either the "Internet address (e.g., URL)" of where the software can found, or a copy of the source code itself. However the EAR do not require such software to be reviewed or approved by BXA, either at the time of original export or any time thereafter; the only requirement is to provide written notification beforehand. The proposed changes to the EAR go on to require (in 740.13(e)(2)) that you "not knowingly export or reexport" the source code (or products developed with it) to the "T7" nations accused by the U.S. of sponsoring international terrorism (Cuba, Iran, Iraq, Libya, North Korea, Sudan, and Syria), but then limit the effect of this prohibition (in 740.13(e)(3)) by stating that it does not apply to "[posting] of the source code on the Internet (e.g. FTP or World Wide Web) where source code may be downloaded by anyone".

Based on the proposed changes to 740.13, the following activities would appear to be permitted for U.S.-based developers and others subject to U.S. jurisdiction:

In these cases written notification to the BXA should include the URL associated with the web site, FTP site, or newsgroup (e.g., "http://...", "ftp://...", or "news://..."). The addresses for written notification are found in 740.17(g) of the proposed changes. As a side note here, U.S. persons making full-strength encryption software available for Internet download have been required to implement access controls on such downloads, as described in 734.2(9)(ii). The proposed changes include a change to 734.2(9)(ii) which in essence exempts open source encryption software in source code form ("source code eligible for export under Section 740.13(e)") from this requirement.

However note that the proposed changes to 740.13 do not (in and of themselves) appear to permit any of the following activities:

(See below for further discussion of how the proposed changes to the regulations affect export of open source software in binary form.)

Another issue of potential concern to open source developers is the EAR prohibition regarding "technical assistance", in 15 CFR 744, "Control Policy: End-User and End-Use Based" [EAR744]. In particular, 744.9, "Restrictions on Technical Assistance by U.S. Persons with Respect to Encryption Items", states that "No U.S. person may, without a license from BXA, provide technical assistance (including training) to foreign persons with the intent to aid a foreign person in the development or manufacture outside the United States of encryption commodities and software that, if of United States origin, would be controlled for 'EI' reasons under ECCN 5A002 or 5D002." This would seem to restrict the ability of U.S. open source developers to provide development or other services to non-U.S. developers working on open source encryption software, even when the software in question was developed outside the U.S.

No changes were proposed to 744.9. However in the existing regulations 744.9(a) goes on to say that "this prohibition does not apply if the U.S. person providing the assistance has a license or is otherwise entitled to export the encryption commodities and software in question to the foreign person(s) receiving the assistance." In the case of open source encryption software in source code form, the proposed changes in 740.13 mean that a U.S. developer is in fact "entitled to export the encryption ... software in question" (except for the specific case of "foreign persons" in the "T7" nations), and therefore the prohibition on "technical assistance" does not apply.

Based on the proposed changes to 740.13 in combination with 744.9 in the existing regulations, it would appear that U.S.-based developers and others subject to U.S. jurisdiction are permitted to provide technical assistance relating to the creation of open source software in source code form, whether that software is of U.S. origin or not, as long as the "foreign person" being assisted is not a national of the "T7" nations. Of course if the technical assistance being provided is provided in the form of a public web page or a posting to a public newsgroup then it is impossible for the developer to ensure that "T7" foreign nationals do not take advantage of the assistance.

Here we can perhaps assume the existence of a "safe harbor" similar to that provided by the proposed language in 740.13(e)(3). Given that posting open source encryption software in source code form to a public Internet site (where it can be "downloaded by anyone") in and of itself does not constitute "knowingly export[ing] or reexport[ing] source code ... to Cuba, Iran, Iraq, Libya, North Korea, Sudan, or Syria" and is therefore permitted, we can perhaps reasonably assume that providing technical assistance relating to such source code in a public Internet forum is also permitted; the only reasonable exception to this permission would seem to be when the assistance is directed specifically to a "T7" foreign national, for example, in response to a question from someone readily identifiable as such a national. (For example, if the questioner's email address has a domain name associated with one of the "T7" countries.)

A remaining ambiguity is associated with providing "technical assistance" relating to build problems and other questions relating to creation of binaries from open source encryption software in source code form; after all, 740.13(e) gives permission only to export encryption software in source code form, it does not in and of itself provide permission to export binaries generated from that source code. And if a U.S. developer does not have permission to export a binary executable implementing encryption functionality, then (by 744.9(a)) they do not have permission to provide technical assistance to "aid a foreign person in the development or manufacture outside the U.S." of such a binary executable. I discuss this issue in more detail below.

Open source encryption software in binary form

However publicly available encryption software is specifically denied equal treatment with other publicly available software, so open source encryption software in binary form is

As noted above, the proposed new language in 740.13(e) allows essentially unrestricted export or reexport of open source software in source form; however 740.13(e) does not in and of itself address the issue of export or reexport of open source software in binary form. (This is not an issue for open source software in general; publicly available software in general, which includes open source software in general, is not subject to regulation under the EAR, as specified in 734.3, and the relevant sections of the EAR do not make a distinction between publicly available software in source form and publicly available software in binary form.)

We must therefore look elsewhere in the EAR and proposed changes to it in order to determine what provisions apply to binaries created from open source software in source form. The proposed changes create a fairly complicated scheme classifying encryption software into various classes and applying different regulations to each class; most classes can be exported using the ENC license exception, as described in 740.17, "Encryption Commodities and Software (ENC)", and 742.15, "Encryption Items". The different classes vary based on the strength of the encryption functionality (56-bit symmetric key length, 64-bit symmetric key length, greater than 64-bit symmetric key length, etc.) and on whether the software is considered "retail" encryption software, "mass market" encryption software, or otherwise. For our purposes we care only about "full strength" encryption software, which may be considered either "retail" software or not.

"Retail" encryption software is discussed in the proposed language for 740.17(a)(3), "Retail encryption commodities and software products", and 742.15(b)(3), "Encryption commodities and software eligible for classification under ECCNs 5A002 and 5D002". Treating encryption software as having "retail" status requires formal review and approval by the Bureau of Export Administration; once approved for "retail" status such software remains classified under 5D002, but may be exported and reexported under the ENC license exception to any end-user in any country (excluding the "T7" nations), regardless of the strength (e.g., key length) of the included encryption functionality. If the software is made available via "free or anonymous download" then you are not required to make any reports to BXA concerning who downloaded the software (see 740.17(g)).

In order to be given "retail" status software must meet a set of criteria of which the most important (for our purposes) are that the encryption software must be "specifically designed for individual consumer use" and that "the cryptographic functionality cannot be easily changed by the user". (This latter criterion implies that "retail" software must be distributed in binary form.) 740.17(a)(3)(iv) gives as examples of retail software "general purpose operating systems and their associated user-interface client software", "programmable database management systems and associated application servers", "low-end servers and application-specific servers (including client-server applications, e.g., Secure Socket Layers (SSL)-based applications)", and (last but not least) "encryption products distributed without charge or through free or anonymous downloads".

"Retail" status is thus potentially available to binary versions of a wide range of open source software that might have encryption functionality: Linux or *BSD kernels, desktop software and window managers, web browsers and web servers, email and news clients, mail transfer agents, news servers, databases, editors, file encryption utilities, and so on. However as noted obtaining such status requires submitting a formal "classification request" to BXA, as described in 740.17(e), and the BXA may either not approve such request or may delay its response indefinitely. Also, "retail" status is not available for products implementing an open cryptographic interface as defined in 772 (see 740.17(f)), so binaries of open source software products would presumably qualify only if they are linked in such a way that the user cannot easily substitute different encryption functionality. (However this does not affect the exportability of source code for open source software implementing an open cryptographic interface; see the final sentence of the proposed 740.17(f)).

Other full-strength encryption software (besides "retail" software) is discussed in 740.17(a)(2), "Encryption commodities and software", and 742.15(b)(2), "Encryption commodities and software eligible for classification under ECCNs 5A002 and 5D002". Such software may be exported or reexported to "any individual, commercial firm, or other non-government end user" (again excluding end users in the "T7" nations, per 740.17(b) and 742.15(b)(2)). The only significant difference from "retail" software appears to be the prohibition against export to "government end users", as defined in Part 772. The proposed language for 734.2(9)(ii) appears to indicate that for software downloaded from the Internet the prohibition against distribution to "government end users" can be met by rejecting access from systems having "government domain names". (".gov" and ".mil", the domain names associated with the U.S. government and military respectively, are given as examples of such names, though I doubt the intent of the EAR is to prevent access to encryption software by U.S. government and military end users.)

[General purpose encryption toolkits, as discussed in 742.15(a)(5) -- does this section actually matter for open source encryption toolkits? Seems to imply that binaries for such toolkits can be exported under license exception ENC to any non-government end users after BXA review and classification (742.15(a)(5)(iv)), which is essentially the same as the treatment for full-strength non-retail software. However there are some additional reporting requirements for "foreign product[s] developed for commercial sale using ... general purpose toolkits", though it is not clear that this would actually be an issue in practice.]

Mixing U.S. and non-U.S. code

[See 742.15(d) for treatment of "foreign products incorporating U.S. encryption source code". Basically says that if non-U.S. developers use U.S.-origin encryption source code then those products "remain subject to the EAR but do not require review and classification by BXA and can be exported or reexported without further authorization by BXA". Seems to imply that use of U.S-developed open source encryption software by non-U.S. developers will cause no problems in practice.]

[What about U.S. use of non-U.S. encryption source code followed by reexport? The "no de minimis" rule would seem to still apply, but export of source code containing mixed U.S./non-U.S. code would seem to present no problem. Binaries are another issue, as discussed above.]


Bureau of Export Administration, <URL:>
Code of Federal Regulations, <URL:>
U.S. Department of Commerce, <URL:>
"Draft II Encryption Export Regulations", <URL:>
Export Administration Regulations (15 CFR Parts 730-774), <URL:>
EAR Part 734 (15 CFR Part 734), "Scope of the Export Administration Regulations", <URL:>
EAR Part 740 (15 CFR Part 740), "License Exceptions", <URL:>
EAR Part 742 (15 CFRPart 742), "Control Policy - CCL Based Controls", <URL:>
EAR Part 744 (15 CFR Part 744), "Control Policy: End-User and End-Use Based", <URL:>
EAR Part 772 (15 CFR Part 772), "Definitions", <URL:>
EAR Part 774 (15 CFR Part 774), "The Commerce Control List", <URL:>
EAR Supplement No. 1 to Part 774, "Commerce Control List", Category 5, "Telecommunications and Information Security", Part 2, "Information Security", <URL:>
EAR Supplement No. 2 to Part 774, "General Technology and Software Notes", <URL:>

Frank Hecker