December 2, 1999

Charlotte Knepper
National Security Council
Old Executive Office Building
Washington, D.C. 20510

Re: BXA Discussion Draft of the New Encryption Export Control Policy

Dear Charlotte:

Members of the Alliance for Network Security (“ANS”) appreciate your invitation to meet with the Interagency Working Group (“IWG”) to review the discussion draft of the new encryption export control policy circulated last week by the Bureau of Export Administration (“BXA”). In anticipation of this meeting, we want to bring several issues to your attention because they are of paramount concern to ANS members. We also have prepared a more detailed analysis of the discussion draft, which is enclosed with this letter.

Our primary concerns with respect to the discussion draft involve the following issues: (1) exports to telecommunications and internet service providers (“Telco/ISPs”), (2) the definition of “retail”, (3) the definition of “government”, (4) restrictions on “open source” software and (5) software distribution via the internet.

Exports to Telco/ISPs

The discussion draft places more restrictions on Telco/ISPs than the White House announcement had indicated. Of primary concern to ANS members is the restriction on services that government owned Telco/ISPs can provide to non-governmental subscribers.

We believe that it simply does not make sense to differentiate between British Telecom, which is privately owned, and Telecom Italia, which is 96% privately owned. In addition, it does not make sense to differentiate between Deutsche Telekom, which is partially government owned, and over one hundred companies with which it competes in Germany, all of which are privately owned. This problem is not limited to Germany and Italy. Most of the world’s largest Telco/ISPs, including France Telcom and Nippon Telephone and Telegraph, among others, have some government ownership, although most are in the process of privatizing.

We recommend that the interim rule eliminate the Telco/ISP ownership criterion, entirely, so that any Telco/ISP can provide any service to any non-government subscriber. At a minimum, PKI products and services should be added to the list of permitted items.

Definition of “Retail”

The definition of “retail” in the discussion draft should be revised in two important respects.

First, the definition should be modified so that competing products receive similar treatment, whether or not they are exported through “retail” channels. Unless the definition of “retail” is modified in this manner, the net effect will be to favor products that are sold through “retail” channels at the expense of competitive products that are not sold through “retail” channels. A good example would be firewalls, virtual private networks and internet applicances. Such an industrial policy should be anathema.

Second, the definition should be modified so that it authorizes provision of retail services to all end-users, including governments. For example, under the current regulations, government employees may use cellular telephone handsets with encryption, even though the cellular infrastructure requires a license, because the handsets are decontrolled. Similarly, under the new regulations, government employees should be able to use web hosting (for example, they could use something like this https://www.hostiserver.com/vps), application hosting, and other services that a service provider might offer to the public at large, because such services are offered as “retail”. One way to accomplish this would be to modify the definition of “Retail encryption commodities and software” in 740.17(a)(3)(i) to include:

. . . servers designed to provide users with services that are the functional equivalent of retail products. Internet, application, or telecommunications service providers may under this license exception use retail encryption commodities or software, including servers designed to provide users with services that are the functional equivalent of retail products, to provide services to any end-user.

Definition of “Government”

The definition of “government” in the discussion draft is especially problematic. For example, the terms “quasi-government agency” and a “state enterprise” that is “performing a governmental function” are undefined and susceptible of very broad interpretation. ANS members would prefer a definition of government that excluded all entities (including federal, state and local) engaged in civil activities. Such a definition would be similar to the regulations that currently apply to the use of License Exception CIV. The definition of “government” might be as follows:

Foreign Government Entity (as applied to encryption items). A foreign government entity is any government department, agency or other entity performing a governmental function, except for entities (federal, state and local) that are engaged in civil activities. Manufacturing or industrial entities or their separate business units (as defined in part 772 of the EAR) that are engaged in the manufacture or distribution of items or services controlled on the Wassenaar Munitions List are not considered to be engaged in civil activities.

Open Source Software

The provisions of the discussion draft that govern commercial software source code, including some types of open source, contain two limitations that will make it very unattractive for companies to release commercial open source software for development by the community of open source developers. The first limitation requires a license for export to governments. Open source software, by its nature, is publicly available. This is often the case for the best small business software programs. A limitation on release to governments is fundamentally inconsistent with the public nature of open source software. The second limitation requires a one-time review of products developed using open source software. Many developers who utilize open source software will do so outside the United States, so there is no realistic means of enforcing this requirement.

Internet Software Distribution

The discussion draft does not adequately deal with internet distribution of software. We believe that the draft should be amended so that encryption software may be distributed to anonymous end-users via the internet. In particular, it is important that software downloads should not be subject to either end-user screening or reporting requirements. The preferred way to do this would be to make all encryption software eligible for “publicly available” treatment under Sections 734.3(b)(3) and 734.7 of the Export Administration Regulations.

We look forward to discussing these and other issues with you at the meeting on December 3. If you would like to discuss any of them in advance of the meeting, please let me know.

Sincerely,

Roszel C. Thomsen II
Counsel
Alliance for Network Security

ANS Comments on BXA’s Discussion Draft Encryption Regulations (November 11, 1999)

December 2, 1999

I. Background

The Commerce Department’s Bureau of Export Administration (“BXA”) published a discussion draft of the encryption export control regulations implementing the White House announcement of September 16, 1999. Comments are due on December 6, 1999.

Purpose

Members of the Alliance for Network Security (“ANS”) will meet with the Interagency Working Group (“IWG”) on December 3, 1999, to discuss the comments on the discussion draft set forth below, among others.

III. Specific Comments

Telco/ISPs

The discussion draft differentiates between telecommunications and internet service providers (“Telco/ISPs”) that are privately owned vs. government owned, and limits the services that such Telco/ISPs may provide to non-governmental vs. governmental end-users. ANS members believe that it makes no sense to differentiate between British Telecom, which is privately owned, and Telecom Italia, which is 96% privately owned. ANS members further believe that it makes no sense to differentiate between Deutsche Telekom, which is partially government owned, and over one hundred companies with which it competes in Germany, all of which are privately owned. Furthermore, restrictions on service that government owned Telco/ISPs can provide to commercial customers are neither supported by the White House announcement nor necessary to protect any articulated national security or law enforcement interest.

Given the clear trend toward privatization of telco/ISPs, like France Telecom, Deutsche Telekom, Telecom Italia, NTT and others, a regulation that places unique constraints on telco/ISPs that are partially government owned places a greater burden on the historic monopolies than their upstart competitors, which is simply another form of U.S. industrial policy, writ large on the world stage.

Historically, most foreign countries have provided telecommunications and internet services to their citizens through a single (monopolist) government agency or government-owned utility. We will refer to these as “incumbent” telco/ISPs. There is a clear trend toward privatization of incumbent telco/ISPs, by governments, worldwide. The underlying reasons are technological advances, growth in data traffic, and deregulation.

Rapid technological advances, combined with the development of decentralized network-based software (i.e., the internet), have led to substantial increases in transmission capacity at lower costs, reducing the value of the fixed networks constructed over many years by incumbent telco/ISPs. In addition, the fixed networks that the incumbent telco/ISPs constructed are optimized for voice, rather than data, whereas data traffic already exceeds voice traffic in many markets (like the U.S. and U.K.) and is predicted to grow much faster in the future. Finally, deregulation has resulted in the formation of alternative network and access providers, challenging the monopolies enjoyed by incumbent telco/ISPs and reducing their profits. In Germany, for example, there are over 100 operators providing fixed telephony services today. In 1997, there was only one.

As a result of these trends, Governments perceive that holding onto their incumbent telco/ISPs is increasingly risky. Incumbent telco/ISPs are no longer safe, utility-type investments, let alone monopolies, as in the past. Therefore, governments are disposing of their incumbent telco/ISPs, through issuance of stocks and bonds to the public and via strategic sales to other investors, in a process known as “privatization”.

Only a handful of incumbent telco/ISPs have been completely privatized. The most prominent example is British Telecom. However, in some cases the government has retained only a token ownership. For example, the Government of Italy has retained only 4% of Telecom Italia. In almost all countries, there is an inexorable trend toward privatization, reflected by the debt and equity offerings and strategic sales described below. (All figures are for 1998, the last year for which statistics are available).

Some governments are privatizing their incumbent telco/ISPs by issuing stock to the public. Altogether, incumbent telco/ISPs raised over $45 billion through equity offerings in 1998. For example, the Swiss Government sold 34% of Swisscom in an initial public offering (“IPO”) that raised $6.4 billion. This was the largest ever equity offering in Switzerland, the largest European IPO of 1998, and the year’s largest privatization IPO. The Japanese Government completed the fourth phase of its privatization of Nippon Telephone and Telegraph, selling 6.28% of the company for $7.3 billion in 1998.

Other governments are privatizing their incumbent telco/ISPs by issuing debt securities that are convertible into stock. For example, French Government raised $2.2 billion through the issuance of debt convertible into shares of France Telecom, and the Singapore Government raised $1 billion in debt convertible into debt of Singapore Telecom, in 1998.

In addition, some governments are privatizing their incumbent telco/ISPs through strategic sales. The Brazilian Government completed the largest Latin American privatization ever, when it sold 12 units of its incumbent, Telebras, for $19 billion to consortia led by Telefonica de Espana, Telecom Italia and Portugal Telecom in 1998. Telecom Italia also purchased a 25% stake in Telecom Austria for $2.4 billion, the largest ever privatization in Austria in 1998.

Total privatizations of incumbent telco/ISPs in 1998 amounted to approximately $50 billion. In addition to the large deals described above, incumbent telco/ISPs in Egypt, Israel, the Czech Republic, Tunisia, Malta, Poland, Qatar, Finland and Greece completed equity offerings in 1998. The Governments of Lithuania, El Salvador, Guatemala and Romania completed strategic sales in 1998. Also, in a second phase of privatization, Bell Atlantic issued a bond exchangeable into its previously acquired 25% of Telecom Corporation of New Zealand in 1998.

In summary, the paths toward privatization in different countries are varied, and the pace may be slower or faster, but the trend is consistent throughout Europe, Asia and Latin America. Governments are privatizing their incumbent telco/ISPs, and allowing new companies to compete with them, throughout the world. Moreover, there is no clear distinction between an incumbent telco and ISP that remains government-owned, or one that has been privatized, in the equipment it must acquire or the services it seeks to provide.

Therefore, we conclude that all telco/ISPs should be authorized to receive all cryptographic products under License Exception, and, further, that they should be authorized to provide any service to any non-governmental customer using any product of their choice, whether or not the product is “retail”. U.S. authorities should take comfort in the fact that telco/ISPs are not authorized to provide services to governments, unless they use only retail products.

ANS members would prefer to eliminate ownership as a criterion, entirely, so that all Telco/ISPs are authorized to provide any service to commercial customers, and would be restricted only in the services that they can provide to governments. However, for discussion purposes, we thought it might be useful to describe why other approaches to this problem were rejected.

For example, ANS members considered an approach whereby the scope of services that government owned Telco/ISPs can provide to commercial subscribers would be expanded beyond the list contained in the discussion draft. However, ANS members were unable to come up with a definitive list of services that Telco/ISPs might wish to provide in the future, as the uses of the internet are expanding rapidly and business models are changing with equal celerity. Therefore, we reject the publication of any sort of list as inherently backward-looking and anachronistic. At a minimum, PKI products and services should be added to the list of permitted items.

In addition, ANS members considered an approach whereby the government would publish a list of countries of concern, and place restrictions on services that government owned Telco/ISPs could offer in those countries. However, ANS members cannot define the countries that might be of concern, beyond the seven embargoed and terrorist countries, and believe that any list published in the EAR would greatly increase the complexity of administering in-house compliance programs. In short, it would be transparent, but far from simple.

A final approach that was considered by ANS members would be to authorize exports to government owned Telco/ISPs for any use by commercial subscribers under Encryption Licensing Arrangements (“ELAs”). ANS members rejected this approach because it is neither simple nor transparent.

Definition of “Retail”
1. Authorize Provision of “Retail Services”

Closely related to the Telco/ISP problem described above is the concept of “retail services”. Telco/ISPs should be authorized to provide retail services to foreign government entities. Retail services might include, for example, hosting of web servers, electronic mail servers, application servers, data warehouses, and other similar services that are offered to the public at large. For example, under the current regulations, government employees may use cellular telephone handsets with encryption, even though the cellular infrastructure requires a license, because the handsets are decontrolled. Similarly, under the new regulations, government employees should be able to use web hosting sites such as Certa Hosting, application hosting, and other services that a service provider might offer to the public at large, because such services are offered as “retail”. One way to accomplish this would be to modify the definition of “Retail encryption commodities and software” in 740.17(a)(3)(i) to include:

Authorize Exports of Products That Compete with Retail Products, Such as Firewall/Virtual Private Networks and Internet Appliances

The definition of “retail” commodities and software in the discussion draft describes explicitly “general purpose operating systems with embedded networking and server capabilities” as well as “routers, networking and cable equipment designed for small office and home office use” as being within the definition of “retail”. Several ANS members develop software and manufacture hardware falling within this definition that include firewall and virtual private network (“VPN”) capabilities. Overall, ANS supports the provision of the discussion draft that would make such products retail. However, ANS remains concerned that competing products, including stand-alone firewall/VPNs and internet appliances, might not be afforded similar treatment. (A similar situation exists with respect to PKI products.) For example, Hewlett-Packard’s Axent and Aventail products, Network Associates’ Gauntlet products, Novell’s BoarderManager product, and Sun Microsystems’ SunScreen products, all compete with similar features that are “bundled” into Microsoft’s Windows 2000 and various small office/home office networking products produced by Cisco, Nortel Networks, Lucent Technologies and 3Com. Unless stand-alone firewall/VPNs are considered as retail, the Export Administration Regulations will in effect favor “bundled” solutions at the expense of “unbundled” solutions.

Definition of “Government”

The definition of “government” is especially problematic. For example, who knows what a “quasi-government agency” is? What is a “state enterprise” that is “performing a governmental function”? What is a “non-research educational facility”? Such terms should be avoided in a regulation that has, among its goals, simplicity and transparency. ANS members would prefer a definition of government that excluded all entities (including federal, state and local) engaged in civil activities. The definition might be as follows:

ANS members also considered a second approach whereby one might exclude state and local entities from the definition of government However, the concept of state and local governments is a peculiarly American means of organizing a federal-style government. It is not easy to discern the equivalent of state and local government in other countries. Therefore, we rejected this approach in favor of an approach whereby any entity engaged in a civil activity would be excluded from the definition of government.

In addition, ANS members considered a third approach, whereby BXA would publish a list of countries of concern, and place restrictions on government entities in those countries. However, ANS members cannot define the countries that might be of concern, beyond the seven embargoed and terrorist countries, and believe that any list published in the EAR would greatly increase the complexity of administering in-house compliance programs. In short, it would be transparent, but far from simple.

A final approach that was considered by ANS members would be to authorize exports to governments under ELAs. ANS members rejected this approach because it is neither simple nor transparent.

A fourth approach would be to authorize exports to governments under ELAs”). ANS members would prefer that the Administration not resort to ELAs, because such an approach is neither simple nor transparent.

Open Source Software

ANS members recognize that the discussion draft treatment of open source software goes beyond the White House announcement of September 16, 1999, and we welcome this new development. Nevertheless, there are two aspects of the treatment of so-called “commercial encryption source code”.

First, it is not possible to restrict the export or reexport of “open source” or “community source” falling within this provision to “non-government end-users”. By definition, such source code is freely available to the public. Anyone, including a government end-user, may download and develop products based on such source code.

Second, it is not possible to require that any new product developed with this source code must be classified by BXA. Parties outside the United States are free to develop products based on the source code, subject to a restriction that derivative products themselves must be “open source” or “community source”.

Rather, we recommend that any licensing of “open source” or “community source” by the U.S. copyright holder to a foreign government entity for commercial use should require a one-time technical review, prior to export, and should fall within the definition of “retail”.

Internet Software Distribution

ANS members believe that the discussion draft does not clearly or adequately address the issue of Internet distribution of software. For example, all encryption software with a symmetric key greater than 64-bits remains subject to EI controls, regardless of whether it is retail, mass market and/or publicly available. Furthermore, the draft fails to amend Section 734.2(b)(9)(ii) regarding the posting of EI-controlled software to the Internet. As a result making electronic downloads of strong encryption items available outside the U.S. and Canada continues to constitute an export of EI controlled items, and thus there will be end-user screening requirements and possibly reporting requirements that will make the current widespread business model of anonymous downloads impossible.

Currently, 56-bit encryption software is widely distributed by U.S. companies to end-users worldwide via the Internet. The vast majority of this software is made available for free through anonymous downloads. Because software with a 56-bit or less symmetric key can be released from EI-controls, and thereby made eligible for “publicly available” treatment, such software is not subject to the EAR and therefore there are no end-user screening requirements. But now that full strength [retail] encryption software is exportable to virtually all end-users worldwide (except those in the T7 countries), and U.S. companies expect that the standard encryption strength for those products will now be greater than 64-bits, these companies will certainly want to continue the widespread business model of distributing some subset of that software via anonymous internet downloads. But if such software is not eligible for publicly available treatment, this may raise insurmountable problems of end-user screening.[1]

If left unchanged, the draft would, in effect, maintain the current situation in which strong encryption software cannot be distributed via the Internet outside of the U.S. and Canada. This will be the case despite the fact that such software can be widely distributed to most or all end-users worldwide through virtually any other distribution channel. Currently, some items, such as product updates and patches are distributed only electronically. If strong encryption products can be sold worldwide under the new policy, it will be important to be able to provide updates and patches to these products electronically. This will be especially important for critical security patches which cannot be distributed in a timely way through any other means.

Thus, the draft should be amended to make it clear that [retail] encryption items can be distributed via anonymous Internet downloads, and that such downloads are not subject to end-user screening or reporting requirements.[2] One way to do that would be to make all [retail] encryption software eligible for “publicly available” treatment under Section 734.3(b)(3) and 734.7. Another way would be to amend Section 734.2(b)(9)(ii) as described in the comments in Part II below.

Items Released from EI Controls

As currently written, the Discussion Draft maintains EI controls on mass market software with an asymmetric key length greater than 64-bits. However, without other changes in the Discussion Draft, maintaining such controls will cause major problems for U.S. software companies.

a) Internet Downloads of Mass Market Software

For example, it could make most Internet distribution of mass market software impossible. Once released from EI controls, mass market software that is publicly available is not subject to the EAR. Thus, it can be freely distributed via the Internet without the need to comply with end-user screening or reporting requirements (which would be impossible in the context of anonymous Internet downloads). However, because the Discussion Draft maintains EI controls on retail products with greater than 64-bit key lengths, these products can be distributed in virtually any manner except the most efficient (and increasingly common) manner of Internet downloads.

b) De Minimis Analysis

Similarly, because EI-controlled software currently is not eligible for de minimis exceptions, maintaining EI controls on greater than 64-bit software could make it impossible for US manufacturers to sell their products to be incorporated into foreign products. If this exclusion is not removed, it will force some companies to continue to produce dual versions of products – one weak encryption version that can be free of EI-controls, and one strong encryption version. If this is the case, the cost savings and the ability to compete with foreign suppliers that were anticipated as a result of the new policy will not come to pass. Given the essentially unfettered exportability of “retail” encryption products, and the very broad exportability of the remaining “non-retail” products, the exclusion from de minimis treatment for EI-controlled items seems to be outdated and unnecessary.

Inconsistencies and Possible Rollback on Asymmetric Key Lengths

Under current rules, encryption items with 56-bit symmetric key lengths and 1024-bit asymmetric key exchange mechanisms (56/1024 bit products) are eligible for release from “EI” controls. We are pleased that under the Discussion Draft, at least mass market encryption items with a 64-bit or less symmetric key length are now also released from EI controls under the new “Cryptography Note.”

However, the Discussion Draft appears to be inconsistent regarding the asymmetric key length that can be released from EI-controls. First, Section 740.17(e)(3) states that products with 40 or 56 bit symmetric key lengths that were previously classified as eligible for License Exception TSU can be upgraded to 64/1024 bit without additional technical review. But this section is unclear whether such products would continue to be released from EI controls and exportable under TSU, or whether they would become subject to EI controls and be exportable under License Exception ENC.

Then, Section 742.15(b)(1)(ii) & (iii) seems to indicate that there has been a rollback of current policy with respect to asymmetric key lengths. After stating that mass market products with 64-bit or less symmetric key lengths may be released from EI controls, that section goes on to state that “key exchange mechanisms up to and including 512 bits . . . may also be eligible for this treatment.” So here, it looks like only 64/512 bit products would be released from EI controls.

Later, the “Cryptography Note” in Part 774 indicates that 5A002 and 5D002 do not control mass market encryption items that “do not contain a ‘symmetric algorithm’ employing a key length exceeding 64-bits,” but there is no criteria with respect to any asymmetric key lengths. So under the terms of Cryptography Note a 64/1024 bit product would be released from “EI” controls

Specific Suggestions
Section 734.2(b)(9)(ii) – Definition of “Export”

The Discussion Draft fails to amend Section 734.2(b)(9)(ii), which defines when posting EI controlled software to the Internet constitutes an export. Under the current definition of “export” that applies to EI-controlled encryption items, making a product available for Internet download is an “export” of the software:

unless the person making the software available takes precautions adequate to prevent unauthorized transfer of such code outside the United States or Canada. Such precautions shall include ensuring that the facility from which the software is available controls the access to and transfers of such software through such measures as:

(A) The access control system, either through automated means or human intervention, checks the address of every system requesting or receiving a transfer and verifies that such systems are located within the United States or Canada;

(B) The access control system provides every requesting or receiving party with notice that the transfer includes or would include cryptographic software subject to export controls under the Export Administration Regulations, and that anyone receiving such a transfer cannot export the software without a license; and

(C) Every party requesting or receiving a transfer of such software must acknowledge affirmatively that he or she understands that the cryptographic software is subject to export controls under the Export Administration Regulations and that anyone receiving the transfer cannot export the software without a license. BXA will consider acknowledgments in electronic form provided that they are adequate to assure legal undertakings similar to written acknowledgments.

This provision recognizes that for software made available via Internet download, there is no perfect screening device, and with anonymous downloads, there is no information at all to screen against a denied parties list. As long as reasonable efforts are made to allow the downloads only within the approved distribution territory, such electronic transfers are not considered “exports” and therefore there is no end-user screening required.

However, under the new policy, the approved distribution territory for EI controlled software is all countries except the T7 countries. Section 734.2(b)(9)(ii) should therefore be amended to reflect the new policy, such that making [retail] encryption software available for electronic download is not within the definition of “export”, so long as there is an access control system that:

(1) checks the address of every system requesting or receiving a transfer and blocks any transfer that appears to originate in an embargoed destination;
(2) provides notice that the software is subject to the EAR and cannot be transferred to the T7 countries; and
(3) requires the recipient to acknowledge this.

If, despite such precautions, posting EI-controlled software to the Internet is considered an “export” which would subject the posting party to impractical screening requirements, the effect would be to preclude Internet distribution of many mass market and/or retail software products.

Section 734.3(b)(3) – Exclusion for EI-Controlled Software from the “Publicly Available” Exception

This section should be eliminated. Given that nearly all “publicly available” EI-controlled software would be exportable under the draft regulations to virtually any end-user worldwide, and given that such software would likely be exempt from reporting requirements under the draft regulations,[3] there seems to be little point in maintaining the exclusion from publicly available treatment.

More importantly, excluding EI-controlled software from publicly available treatment could result in Internet distribution of free software (such as components, updates and patches for retail products) being subjected to end-user screening requirements that would be impossible to comply with. The ability to take advantage of publicly available treatment for free software downloads is necessary in order to make such distributions lawful under the draft regulations.

Section 734.4(b)(2) & (h) – De Minimis Exclusion for EI Controlled Items

In this section, paragraph (b)(2) should be eliminated, and paragraph (h) should be amended to reflect that deletion. Or, at the very least, these paragraphs should be amended to apply only to “non-retail” EI controlled items.

As described in Part I of these comments, maintaining the de minimis exception for [retail] EI-controlled items could make it impossible for US manufacturers to supply their products to foreign manufacturers for incorporation into foreign products. If this exclusion is not removed, it will force some companies to continue to produce dual versions of products – one weak encryption version that can be free of EI-controls, and one strong encryption version. If this is the case, the cost savings and the ability to compete with foreign suppliers that were anticipated as a result of the new policy will not come to pass. Given the essentially unfettered exportability of “retail” encryption products, and the very broad exportability of the remaining “non-retail” products, the exclusion from de minimis treatment for EI-controlled items seems to be outdated and unnecessary.

Section 734.7(c) – Published Information and Software

New paragraph (c) provides that software controlled under ECCN 5D002 for “EI” reasons remains subject to the EAR even if it is “published” as defined in paragraphs (a) and (b) of that section. However, for the reasons described in Part I paragraph B(1) of these comments, and in the discussion of Section 734.3(b)(3) above, this can be very problematic for Internet distribution of mass market [retail] software and well as de minimis incorporation of such items into foreign products. Thus, unless other changes are made in the Discussion Draft to address these problems, this paragraph should be deleted and it should be made clear that “published” encryption software of any key length is not subject to the EAR.

Section 734.13(d)(2) – EI-Controlled Software Ineligible for License Exception TSU

This section should make it clear that software controlled under ECCN 5D002 can be released from EI-controls and thereby be made eligible for License Exception TSU if it meets the criteria of “publicly available” under Section 734.3(b)(3).

6. Section 734.13(e) – Non-Commercial Source Code released from EI-Controls

Releasing only “non-commercial” source code may provide an unfair advantage to businesses that rely on an “open source” software development model. Even if object code software compiled from this released open source is not itself released from EI controls, parallel independent compilation of common source code will certainly occur. Moreover, this exception, as written, would in effect release software containing “open CAPIs” if the source code for those CAPIs is available as open source. This could put products with closed CAPIs at a competitive disadvantage because of the licensing requirements that will still affect the enabling of cryptographic code.

7. Section 740.17(a)(1) – Exports to U.S. Subsidiaries

We are pleased that the Discussion Draft permits the export of EI controlled commodities, software and technology to subsidiaries of US companies. However, such exports should be exempt from the prior technical review requirement of 740.17(e). U.S. companies with foreign facilities increasingly develop products using “virtual” teams consisting of developers located in many different locations. As a result, technology and software code may be exchanged on a daily basis, and this code may be continually evolving. A literal reading of the current Discussion Draft would require a new technical review every time the code changed in such a way that the “functional encryption capacity [is] modified or enhanced” (see 770.2(n) – Interpretation 14). Such frequency of technical reviews, with 30-day delays each time, would obviously cripple such collaborative product development within U.S. companies. Moreover, it is unclear what a technical review of encryption “technology” would even entail. In any case, since all such software and technology remains subject to U.S. controls, as does any product developed by the U.S. company that incorporates such software or technology, there is no reason for any technical review until the product development process is complete or nearly complete. Even then, rigorous software tests must also be carried out to ensure that everything is working as it should be. For more information about software testing, head to the Parasoft website. Thus, a clarification regarding the need for prior technical reviews for exports to U.S. subsidiaries is needed in this section.

8. Section 740.17(a)(3) – Definition of “Retail”

The definition of “retail” in the Discussion Draft should make it clear that paragraph (a)(3)(i) is a non-exclusive list of “retail” products. Thus, it should begin, “(i) As examples, retail encryption products include, but are not necessarily limited to, . . .”

On the substance of the “retail” definition, terms such as “retail outlet” and “specifically designed for individual consumer use” are left undefined. Is a “retail outlet” any third party reseller that distributes products in tangible form to its customers? Based upon the illustrative list of “retail” products in paragraph (a)(3)(i), it seems clear that “specifically designed for individual consumer use” applies to products that can be used both by individual consumers and by enterprises and other groups.

Section 740.17(e) – Technical Review

As described in the comment on 740.17(a)(1), above, the Discussion Draft should be amended so as to make clear that prior technical reviews are not required for exports of encryption software and technology to U.S. subsidiaries.

Section 740.17(g) – Reporting Requirements

As currently drafted, the reporting requirements are unclear and possibly inconsistent. Moreover, they could be read as precluding most Internet distribution of EI controlled software.

Paragraph (g)(1) indicates that there is no reporting for exports of retail products to individual consumers. But then paragraph (g)(2) states that exporters must report all available information (name and address of recipient and quantity exported) for items exported though direct sale (and for indirect sales if the end-user is known). Are the reports required under (g)(2) limited to direct sales of non-retail products and direct sales of retail products to recipients other than individual consumers? What about Internet downloads where there is no way to know whether the recipient is an individual, a commercial entity, or a government?

Following the September 16 policy announcement, companies and industry groups were repeatedly reassured that reporting requirements will not require exporters to implement new systems or collect more information than they are currently doing. However, may U.S. software companies currently rely on anonymous Internet downloads to provide product updates, add-on components, and critical patches. If the reporting requirements mandate that U.S. companies report recipient name and address for all “direct” distributions of software via the Internet, this would impose enormous new information and screening requirements.

We are hopeful that the use in paragraph (g)(2) of the term “all available information” means that U.S. companies will not be required to gather any particular information, but only report that information that becomes available though normal business operations. But that should be made more clear. Specifically, a new subsection should be added to paragraph (g)(1) which states that no reporting is required for exports of “encryption software distributed via anonymous Internet downloads.”[4]

Regarding the timing of the reports, in some cases one month from the end of the reporting period may not be enough time for all sales data that is potentially collected to filter back into the central corporate databases such that it would be available for inclusion on reports to BXA. Because U.S. exporters are required to provide “all available” data, we assume that this means all such data that is available at the time the report is due. If this is not the case, this should be clarified.

Finally, the electronic reporting requirement, along with the proposed methods of submission, raises some very serious security concerns. This rule would have U.S. companies compile a complete and detailed report of their business activity (including recipient names/addresses and volumes – the complete basis for a company’s revenue) in a single electronic file. This extremely valuable and proprietary information would then be concentrated twice a year at two widely publicized times and places – an almost irresistible target for foreign and/or commercial espionage. By suggesting the insecure transmission of such data via e-mail, surface mail and courier services to two separate addresses, the Discussion Draft may inadvertently expose U.S. exporters to unnecessary risks. Thus, while the draft states that “exporters may request other reporting arrangements with BXA,” it should also suggest more secure methods of transmission such as encrypted files and separate hand deliveries to a trusted official of each of the two agencies.

11. Part 774, Part II – “Information Security”, Note 3: Cryptography Note

For the reasons set out in several sections of these comments, the Cryptography Note should include a section stating that ECCN 5D002 does not control software that is publicly available.

Conclusion

ANS members look forward to discussion of these and other issued with members of the IWG on December 3, 1999.

[1] While end-user screening is impossible in the context of Internet downloads, some type of country level screening can be done. For example, systems can be designed to check the address of every requesting system and can block downloads to systems that appear to be located in a prohibited destination.

[2] U.S. companies could report the number of downloads, but it is unlikely that such information would be useful. In any case, Section 740.17(g)(2)(ii) requires reporting for items exported through “direct sale,” and we understand that the use of the term “sale” was intentional in order to indicate that free electronic distribution of software is not subject to reporting requirements.

[3] Section 740.17(g)(2)(ii) requires reporting for items exported through “direct sale.” We have been told that the use of the term “sale” was intentional in order to indicate that free electronic distribution of software is not subject to reporting requirements. Publicly available software is normally distributed for free, there would be no “sale” subjecting such distributions to reporting.

[4] See also the recommendation regarding Section 734.2(b)(9)(ii) above.