26 February 1997
Source: http://www.bxa.doc.gov/22-.pdf (525K)

Public Comments on Encryption Items Transferred from
the U.S. Munitions List to the Commerce Control List

# 22. William A. Root

William A. Root
4024 Franklin Street
Kensington, MD 20895
Tel. & FAX 301 942 6720

February 11, 1997

Nancy Crowe, Regulatory Policy Division
Office of Exporter Services, Bureau of Export Administration
Department of Commerce, Room 2705
14th Street and Pennsylvania Avenue NW
Washington DC 20230

Re: Encryption Items Transferred From the U.S. Munitions List to the Commerce Control List, Interim rule effective December 30, 1996

Dear Ms. Crowe:

This letter is in response to the invitation for comments contained in the Federal Register dated December 30, 1996.

Publicly available

It is recommended that controls on publicly available information be limited to commercial transactions involving furnishing technical assistance based on such information.

This would be consistent with a July 1981 opinion of the Office of Legal Counsel in the Department of Justice, in a memorandum to the Departments of State and Commerce entitled Constitutionality of the Proposed Revision of the Technical Data Provisions of the International Traffic in Arms Regulations and Memorandum re Export Administration Regulations, to the effect that scientific and technological speech is fully protected so long as the speech is not directly related to a commercial transaction.

It would also be consistent with the lack of ITAR control on information in the public domain (22 CFR 125.1(a)) coupled with the requirement for approval for furnishing a defense service even if:

> all the information relied upon by the U.S. person in performing the defense service is in the public domain (2 CFR 124.1(a)).

In order to reconcile 124.1(a) with 125.1(a), a controlled defense service must add value to the publicly available information, i.e., it would not qualify for the definition of "published" in 734.7(a)(1), which reads:

> available for general distribution to any member of the public or to a community of persons interested in the subject matter, such as those in a scientific or engineering discipline, either free or at a price that does not exceed the cost of reproduction and distribution.

The EAR equivalent of ITAR 125.1(a) is:

> the removal from "subject to the EAR" of publicly available technology and software pursuant to 732.2(b), 734.3(b)(2), 734.3(b)(3), 734.7, 734.8, 734.9, and 734 Supplement l; and

> License Exception GSN, described in 740.13(d), if the price does not exceed the cost of reproduction and distribution.

The EAR equivalent of ITAR 124.1(a) is the requirement for a license to provide technical assistance found in 744.9.

Therefore, pursuant to this recommendation, the December 30, 1996, interim rule would be revised to:

> revert to the texts in effect prior to December 13, 1996, for 732.2(b), 734.3(b)(3~, 734.7, 734.8, 734.9, and 734 Supplement 1;

> add at the end of the first sentence of 740.13(d)(2) "if the price exceeds the cost of reproduction and distribution";

> in the first sentence of 742.15(b)(1):

> > delete "certain";

> > after "Presidential Memorandum of November 15, 1996" insert "eligible for License Exception GSN except that the price exceeds the cost of reproduction and distribution:; and

> > change "be released from "EI" controls and thereby made eligible for mass market treatment" to "nevertheless become eligible for License Exception GSN";

> in the second sentence of 742.15(b)(1), change "eligibility for mass market treatment" to "such eligibility for License Exception GSN";

> in the redefinition of "commodity" in part 772, delete:

> > Note that the provisions of the EAR applicable to the control of software (e.g. publicly available provisions) are not applicable to encryption software.

> delete "even when made publicly available in accordance with part 734 of the EAR, and it" from the Note at the end of License Requirements for ECCN 5D002;

> revise the first sentence of 744.9 as follows:

> > No U.S. person ... may, without a license or other authorization from BXA, provide technical assistance to foreign persons (including training and including instances in which all the information relied upon by the U.S. person in providing technical assistance is "publicly available" as that term is interpreted in 734.3(b)(2), 734.3(b)(3), or 740.13(d) if the price for the technical assistance exceeds the cost of reproduction and distribution of that information) 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.

If, for whatever reason, the above recommendation is not accepted, it is recommended that, at least, the exclusions of encryption software from exceptions from "subject to the EAR" be removed for release at an open conference, fundamental research, and educational information. These exclusions appear to be inadvertent, as evidenced by the following statement in 744.9:

> ... the mere teaching or discussion of information about cryptography, including, for example, in an academic setting, by itself would not establish the intent described in this section, even where foreign persons are present.

Encryption software as a commodity

The first Note under 5D002 License Requirements states:

> ... encryption software is treated under the EAR as a commodity included in ECCN 5A002.

and the redefinition of "commodity" in part 772 states:

> ... the provisions of the EAR applicable to the control of software ... are not applicable to encryption software.

However, the regulation does apply software provisions to encryption software, e.g., in ECCN 5~002 itself and in License Exceptions KMI and GSN after one-time reviews. The redefinition of "commodity" in part 772 also includes:

> Encryption software is controlled because, like the items controlled under ECCN 5A002, it has a functional capacity to encrypt information on a computer system, and not because of any informational or theoretical value that such software may reflect, contain or represent, or that its export may convey to others abroad.

Substantially identical statements appear in the introductory paragraph to 742.15 and in the first Note under 5D002 License Requirements. The apparent intent is to rebut arguments that these controls inhibit free speech. Such a rebuttal has been challenged in the Bernstein case.

If, despite the rebuttal, the statement is to be retained, it is recommended that confusion be reduced by leaving it in 742.15 but deleting the first 5D002 License Requirement Note altogether and changing the definition of "commodity" back to its pre-December 30 text.

License Exception TSU

The statement in 740.13(d)(2) that License Exception TSU is not available for 5D002 encryption software is inconsistent with 742.15(b)(1), which, in effect, makes the GSN mass market software portion of TSU available after a one-time review. The SUD portion of TSU would become available if the software being updated were mass market software approved for GSN treatment. The OTS and STS portions of TSU would also become available; but this would have no practical effect, since GSN would be available whether or not the software was "operation" or "sales."

740.8(d)(2) envisages use of License Exception KMI for only six months and 742 Supplement 7 specifies commitments to key recovery products and services and a key management infrastructure as preconditions for 56-bit DES: whereas 742.15(b)(1) permits applicability of License Exception TSU after a one-time review to mass market software regardless of bit-length.

No provision was found to make SUD applicable for updates of software approved for License Exception KMI or for encryption software approved in response to a license application. Government review of exports of such software would be unnecessary, because SUD is limited to updates which do "not enhance the functional capacities of the original software."

It is, therefore, recommended that:

> 740.8(d)(2) be revised for consistency with 742.15(b)(1) or vice versa; and

> 740.13(d)(2) be revised to read:

> > Software not eligible for this License Exception. The OTS, STS, and GSN portions of License Exception TSU are not available for encryption software controlled for "EI" reasons under ECCN 5D002 if the price exceeds the cost of reproduction and distribution except after a one-time review as described in 742.15(b)(1), 742 Supplement No. 6, and 748.3(b).

License Exceptions other than TSU and KMI

Encryption software eligibility for License Exception BETA is explicitly conditioned upon a one-time BXA review and encryption software is explicitly ineligible for the cooperating government portions of License Exception GOV'T. In the absence of explicit encryption software conditional eligibility or ineligibility for License Exceptions TEMP, SNR, SAFE, the U.S. Government portions of GOV'T, BAG, and various portions of APR, one might presume unconditional eligibility for these exceptions. However, doubt is cast on this presumption by:

> the 5D002 statement that encryption software is treated as a commodity;

> the "commodity" definition statement that EAR provisions applicable to the control of software are not applicable to encryption software;

> the following from the second Note under 5D002 License Requirements (underlining added):

> > After a one-time BXA 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;

and

> the following from 742.15(b)(1) (underlining added):

> > If, after a one-time review, BXA determines that the software is released from EI controls, such software is eligible for all provisions of the EAR applicable to other software, such as License Exception TSU for massmarket software.

There is no point in making BETA, TEMP, SNR, SAFE, the U.S. Government portions of GOV'T, BAG, and various portions of APR applicable after a one-time review which makes GSN or KMI applicable, since the only reason for considering these other License Exceptions would be the inapplicability of GSN or KMI.

Informal BXA advice indicates an intent to permit travelers to carry personally-owned laptops loaded with encryption software under License Exception BAG and to carry company-owned laptops loaded with encryption software under License Exception TEMP. This would not be possible if one or more of the provisions listed above overcomes the presumption of unconditional encryption software eligibility for these License Exceptions. Strong arguments can also be made for encryption software eligibility for the other listed License Exceptions not declared ineligible or conditional upon one-time review.

Therefore, in addition to the above recommendations under "Encryption software as a commodity," deletion of the following is recommended:

> "as well as other provisions of the EAR applicable to software" in the second Note under 5D002 License Requirements; and

> "all provisions of the EAR applicable to other software, such as" in 742.15(b)(1).

De minimis

There is no point to conditioning applicability of de mini~is rules on the one-time BXA review for License Exception GSN eligibility ((734.4(b)(2)). If eligible for GSN, no license is required even if the de minimis limits are exceeded.

There is already a requirement for BXA review prior to any reliance upon the de minimis exclusion for software or technology (734 Supplement 2 (b)).

It is recommended that encryption commodities, software, and technology be eligible for the de minimis exclusion based on a one-time review for that purpose only, so that U.S.-origin encryption commodities, software, or technology not eligible for GSN, KMI, or any other License Exception could be reexported if trivial in both quantity and quality.

Classification requests

Proposed 740.8(b), 742.15(b)(1), and 748.3(b)(3) seem to require that, after exporter #1 has obtained a classification, exporters #2, #3, etc. must, nevertheless, submit additional classification requests for the identical product. This would be unnecessarily burdensome for both exporters and the Government.

If exporter #1 chose to keep its classification request confidential, there may be no way to avoid multiple requests for the same product. Otherwise, however, there would be no apparent reason to require exporter #2 to submit another identical classification request.

If the purpose of the classification request includes factors other than confirmation of the technical characteristics of the product (e.g., the identification of a key recovery agent), complying with those factors could be made a condition for exporter #2 to benefit from the classification obtained by exporter #1. However, there is no apparent reason for an exporter #2 who is aware of favorable action on exporter #l's request and would comply with all other conditions, including use of the same key recovery agent, to submit any request in order to benefit from the release from EI controls granted to exporter #1. Moreover, there is no apparent reason for an exporter #3 in the same situation as exporter #2 except for the designation of a different key recovery agent to request anything more than approval of the new key recovery agent.

It is, therefore, recommended that:

> as soon as possible, the one-time BXA review for License Exceptions GSN and KMI be replaced by eligibility based only on a technical description coupled, if necessary, by a requirement, prior to export, to inform BXA of having fulfilled other conditions, such as notification of a key recovery agent;

> in the meantime:

> > the requirement to submit an encryption classification request be waived if favorable action has already been taken on an identical request;

> > the requirement to submit technical detail be waived if the only purpose of a classification request would be to designate a new key recovery agent;

> > BXA ask all encryption classification requesters for permission to publish action taken on their requests, if favorable; and

> > BXA publish, preferably in the Federal Register, such favorable actions.

"Hooks" and encryption "holes"

According to informal advice from the Government, software from which encryption capability has been removed is still controlled as encryption software if the ''hooks," which facilitate addition of encryption by the importer, are still in place. This is known as an encryption "hole." There is nothing in the regulation which explicitly states this. Perhaps the following from ECCN 5D002.a. is interpreted to control encryption holes" or ''hooks":

> "Software" specially designed or modified for the ... "use" of ... "software" controlled by ... 5D002.

However, most exporters would probably assume that encryption software controls do not apply if the encryption capability is removed. Thus, those who are aware of the informal advice that "EI" controls apply even if the only encryption-related software is in the form of "hooks" are at a competitive disadvantage.

It is therefore recommended that, if "hooks" in the absence of any other encryption feature must be controlled, this be stated explicitly in ECCN 5D002.

Terminology

The expression "up to 56-bit" used in numerous places in 742.15(b)(3) does not literally include 56-bit. However, "56-bit key length DES, or equivalent" in 742 Supplement 7 indicates that "up to 56-bit" in 742.15(b)(3) is intended to mean "up to and including 56-bit".

The expression "key management infrastructure" is used both to identify a License Exception (740.8) and to describe conditions which must be met for eligibility for this License Exception (742 Supplement 4 (8) and 742 Supplement 7 (3)(i)). Using other terminology for either the License Exception or the conditions might avoid confusion.

"Key recovery agent" must be individual(s), per 742 Supplement 5 I.(1)(a); but the term is used to describe a corporate entity elsewhere, e.g., responsibility to certify that such individual(s) meet specified requirements, to disclose to BXA when an individual no longer meets those requirements, and to submit evidence of the "key recovery agent's corporate viability and financial responsibility", per 742 Supplement 5 I.(1)(b), (2), and (5). Different terminology should be used to identify the entity providing certifications or disclosures concerning the individual(s) who is(are) the key recovery agent.

The definition of "U.S. person" in 744.9(b) omits "or a protected individual as defined by 8 U.S.C. 1324b(a)(3)", which appears in the definition of "U.S. person" in 744.6(c). There is no apparent reason to have two different definitions of the same term in the same part of the EAR.

Sincerely yours,

William A. Root

Hypertext by DN and JYA/Urban Deadline