Encryption Export Controls
Released: 2001-01-11T00:00:00

Background

Encryption is a means of scrambling data so that parties may send and receive private messages. (1) It may also be used forauthentication (confirming the identity of the sender) and data integrity (ensuring that a message has not beenchanged intransit). Contemporary encryption is generally based on an algorithm paired with a "key" -- usually a string of 40to 128bits -- which together protect messages from computer-based descrambling by outsiders.

Keys may be secret or public. Under the former, both the sender and the recipient share an identical key. A public keysystem involves a related pair of keys, one of which is published in a public directory and the other remaining withthesender or recipient. Public key systems are useful for encrypting messages in large and open computer networkssuch asthe Internet, where individual users may not have previous knowledge of one another. Key escrow or recoverysystemsmake it possible for parties other than those who are party to an encrypted conversation or who encrypt data forstorage tohave access to the secure material. This capability is viewed favorably by law enforcement since key access enablesauthorities to decrypt so-called "real time" messages without the knowledge or consent of parties to acommunication or todecrypt stored data for investigatory purposes. Key escrow or recovery systems may also be of general commercialbenefitin the event a key is lost, stolen, or destroyed.

The development and use of strong computerized encryption in the United States was originally limited to the federalgovernment for military and intelligence applications. (2) Eventually, the increasing use of computers for commercialpurposes led to a need for stronger commercial encryption as well. In 1971, IBM completed the development ofa ciphercode with a 128-bit key, turning it into a marketable product by 1974. At the same time, the federal governmentbegan tosolicit bids for an encryption algorithm that could be used as a federal standard for storing and transmittingunclassifieddata - known as a data encryption standard (DES). IBM reportedly responded with a 56-bit key and othermodificationsafter discussions with the National Security Agency (NSA), the federal entity responsible for communicationsintelligence,which had earlier taken considerable interest in its project. As stated in a Senate report, NSA "certified that ... [therevisedIBM cipher] was, to the best of their knowledge, free of any statistical or mathematical weaknesses" (3) and recommended itfor use as the new DES.

Critics suggested possible vulnerabilities in the shortened key and pointed out the inherent (and continuing) dilemma in theconfrontation of governmental and business interests in the area. One author states that "[s]ince the DES wouldeventuallybe manufactured commercially and installed on a wide assortment of equipment sold abroad, the NSA would notwant tocut its own throat by permitting the foreign proliferation of an unbreakable cipher. Yet weaknesses in the cipherwould stillallow the Agency to penetrate every communications link and data bank using the DES, American as well asforeign." (4)

While the current DES is based on a 56-bit key, the National Institute of Standards and Technology (NIST) in 1997 beganto develop an Advanced Encryption Standard (AES) with a key length of from 128 to 256-bits. (5) In October 2000, NISTannounced its choice for this new AES algorithm - the Rijndael - which will be proposed for incorporation in a newDraftFederal Information Processing Standard (FIPS). Following a public comment period and any subsequent revisions,theSecretary of Commerce will decide whether to adopt the FIPS as an official government standard. (6)

With the growth of the global economy, the business community has continued to express a need for strong encryption fordomestic use and cross-border communications and transactions. While there are no statutory restrictions on thedomesticuse of encryption, the computer industry argues that restrictive export controls have hampered U.S. technologicaldevelopment since it is impracticable to develop separate products for the domestic and foreign market; that exportrestrictions will hinder its long-term competitiveness, given the increasing availability of strong foreigncryptography andthe projected increase in demand for such products due to the increasing popularity of electronic commerce; andthat U.S.interests are harmed by making increasingly strong U.S. encryption unavailable to legitimate users worldwide. (7) At thesame time the federal government argues that because of its national security and law enforcement responsibilitiesit shouldnot facilitate the proliferation of encryption despite its foreign availability and the increasing capability of privatecomputerusers to invade encrypted systems. (8) TheAdministration has advocated the development of a key managementinfrastructure (KMI), in which third-parties would maintain an extra key to an encrypted system, as an indispensableelement of worldwide use of public key encryption. (9) In response to such proposals, business, consumer, and privacygroups have expressed numerous concerns over the governmental role in determining who may hold escrowed keysandover who may obtain access to encrypted transactions and data. The Administration has since deemphasized theuse ofexport controls to foster KMI development.

Current Export Controls over Encryption

Encryption had traditionally been treated as a munition subject to Cold War export restrictions imposed by theCoordinating Committee for Multilateral Export Controls (CoCom). Encryption currently appears both as amunition and adual-use item on lists maintained by CoCom's successor, the 33-member Wassenaar Arrangement. (10) A Cryptography Noteto the dual-use list added in December 1998 requires Wassenaar members to review exports of mass markethardware andencryption with a key length greater than 64 bits in light of their respective export control regimes; this policyreplaces theearlier General Software Note, which did not restrict the export of mass market encryption software. (11)

Encryption is subject to U.S. export controls under both the Arms Export Control Act (AECA) and the Export Administration Act of 1979 (EAA). Section 38 of the AECA, 22 U.S.C. ï¿½ 2778, authorizes the President to controlthecommercial export of defense articles and services and to establish a United States Munitions List (USML)delineatingthese articles. The AECA is administered by the State Department through its Office of Defense Trade Controls(DTC), asub-unit of the Department's Bureau of Politico-Military Affairs. (12) The Department implements the Act through theInternational Traffic in Arms Regulations (ITARS), set forth in 22 C.F.R. Parts 120 through 130. Arms exportersmustregister with the federal government and obtain licenses before items may be exported. The designation of itemsas defensearticles and defense services for regulation under the AECA is not judicially reviewable. (13) Unlike the EAA, the AECAdoes not require foreign availability to be taken into account in licensing decisions. Section 38 provides thePresident withstrong enforcement authorities and authorizes stringent criminal and civil penalties for those who violate the AECAand itsimplementing regulations. The NSA has played a role in the licensing process, advising as to the national securityimpactof an export and examining such factors as the sensitivity of a product and its end users; it has also providedtechnicaladvice in the determination of whether an item belongs on the USML. (14)

In implementing the AECA, the State Department may decide that a product is not defense-related and transferjurisdiction over that item to the Bureau of Export Administration (BXA) of the Department of Commerce(DOC). (15) TheExport Administration Act of 1979 (EAA), which was recently reauthorized until August 20, 2001, authorizes theCommerce Department to control exports for national security, foreign policy, and short supply reasons. (16) Items subject toEAA regulation are listed in the Commerce Control List (CCL), 15 C.F.R. ï¿½ 799.1, Supp. No. 1.

Originally, virtually all encryption was classified as a defense article and regulated under the AECA. (17) In the early 1990'sthe Department of State had exempted from AECA control nine types of encryption (including smart cards andencryptionfor use in financial transactions) and transferred authority over these items to the Commerce Department. (18) Jurisdictionover encryption exports could also be transferred to DOC for mass market software under an expedited commodityjurisdiction procedure (19) and as a result ofcase-by-case review. (20) As a general policy, theState Department allowedexports of commercial encryption with 40-bit keys, although some software with DES could be exported toU.S.-controlledsubsidiaries and financial institutions. (21)

The Clinton Administration announced a new encryption policy in October 1996, giving DOC jurisdiction over allcommercial encryption, though subject to conditions many of which were similar to those imposed under the AECA( e.g. ,EAA foreign availability provisions were inapplicable). (22) The President's Executive Order made approvals subject to aninteragency review process and gave the Justice Department a vote in determining encryption export policy. Keyrecoveryencryption of unlimited key length could be exported as could 56-bit non-recovery encryption if the manufactureragreed todevelop a recovery system within 2 years. In May 1997, DOC eased controls over encryption for financial purposes,announcing that, after a one-time review, it would approve exports of unlimited key length "specifically designedto supportfinancial transactions" and, for 2 years, strong general purpose non-recovery encryption "when used for interbankandsimilar financial transactions" once producers agreed to develop a recoverable product. (23)

In 1998, the Clinton Administration changed its key recovery policy, allowing the export of 56-bit encryption to alldestinations except embargoed/terrorist countries under a license exception after a one-time agency review andwithout acommitment to produce a key recovery product. While a license exception continued to be available for encryptionofunlimited key length that contained a key recovery feature, a requirement that the government pre-approve a keyrecoveryagent was eliminated. In addition, the favorable export treatment previously granted financial institutions wasextended toinsurance companies, health and medical end-users, and, with some end-use restrictions, on-line merchants. Following aone-time agency review, U.S. companies could also export encryption of any key length for internal companyproprietaryuse to their subsidiaries in all but embargoed destinations. Products of any key length for use by commercial entitiesinsome 45 countries and, for companies headquartered in 22 countries (including the United States), their worldwidesubsidiaries located anywhere but in embargoed destinations, were exportable after review. This policy also allowedtheexport of "recoverable" encryption, that is, encryption that allows access to plaintext by law enforcement and others,butdoes so without a key recovery feature. The Administration also announced plans to establish a technical supportcenterrun by the FBI to provide federal, state, and local law enforcement with the funds and expertise needed to deal withdevelopments in encryption technology. (24)

Further relaxation of encryption export controls took place in September 1999, when the Clinton Administration announcedthat encryption items of any key length may now be exported under a license exception, after a technical review,toindividuals, firms, and other non-government end-users in any country except for seven state supporters ofterrorism. (25) After a technical review, retail encryption commodities and software of any key length will also be exportable underalicense exception to any recipient in any country except for the same seven destinations. Post-export reporting willberequired, however, for any export to a non-U.S. entity of any product over 64 bits. The Administration alsoannounced thatit would implement the updated Wassenaar controls, allowing 56-bit DES and equivalent products to be exportedwithout alicense to all users and destinations, except the seven terrorist countries, after a technical review. It would alsomakeencryption items of 64-bits or less that meet the mass market requirements of the Wassenaar cryptographic noteeligible forexport without a license after a technical review. The Clinton Administration further announced that foreignnationalsworking in the United States will no longer need to obtain an export license in order to work on encryption for U.S.firms. Following criticism by companies, privacy groups, and Internet proponents, the Administration postponedpublication ofthe implementing regulations and expanded certain aspects of the earlier proposal in new rules that were issuedJanuary 14,2000. (26) Among other things, DOC broadenedthe encryption license exception as it applies to source code; expanded themeaning of "retail" to include the provision of encryption through mail order, electronic, or telephone calltransactions;and made the encryption license exception available for exports to government entities that are telecommunicationscompanies and Internet service providers, so long as the export does not involve a non-retail product that will beused toprovide services specific to government end-users.

Concurrent with the Clinton Administration's announcement was the President's proposal of the Cyberspace ElectronicSecurity Act of 1999, which would set forth limitations on the government's use and disclosure of encryption keysobtainedunder court order, address the disclosure and use of stored recovery information by recovery agents for governmentalpurposes, and authorize appropriations for the FBI's Technical Support Center. (27)

On July 17, 2000, the Clinton Administration announced that it would further streamline controls for encryption exports to23 countries, including European Union member states, removing distinctions between government andnon-governmentend users and generally eliminating the 30-day waiting period following the exporter's submission of a classificationrequest. (28) Implementing regulations were issuedOctober 19, 2000. (29)

First Amendment Issues

Because AECA regulations treat the disclosure of encryption software and technical data to a foreign personas an export,strict AECA penalties could apply to individuals who discuss developments in advanced cryptography at domesticconferences attended by foreign persons and over computer networks with foreign participants without firstobtaining anexport license. (30) It has been argued that theseaspects of the AECA -- and now EAA -- regulatory regime constitute aprior restraint of protected speech in violation of the First Amendment. (31) Federal district courts addressing this issue overthe last three years have both upheld and dismissed First Amendment challenges to export licensing schemes forencryption. In the first circuit court opinion issued during this period, the Court of Appeals for the Ninth Circuit,on May 8,1999, affirmed a lower court ruling striking Department of Commerce regulations as an unconstitutional priorrestraint. (32)

Court challenges have generally involved restrictions on the export of software containing encryption source code -- thatis, computer programming language describing an encryption program or an algorithm. This original programminglanguage must be combined or translated into object code, which enables a computer to read the encryptionprogram. (33) Distinctions are generally raised between the expressive and functional nature of the software at issue, and betweenthe actof exporting software containing encryption source code and the use of source code to communicate. In his 1996ExecutiveOrder, the President expressly stated that "the export of encryption software, like the export of other encryptiondescribedin ... [the order], must be controlled because of such software's functional capacity, rather than because of anypossibleinformation value of such software." (34) At the sametime, it is argued that, regardless of the functional capability ofsoftware, the source code it contains is a language by which cryptographers convey mathematical ideas to each otherand,as such, merits the strongest First Amendment protection.

Bernstein Cases

In Bernstein v. Dep't of State, a California federal district court, ruling on a government motion to dismiss, held that sourcecode constituted speech protected by the First Amendment. (35) The court later ruled that AECA licensing requirementswere an unconstitutional prior restraint on such speech. (36) The plaintiff subsequently challenged the 1996 DOC regulationson First Amendment grounds, the court holding these unconstitutional as well and enjoining their application to theplaintiff. (37) The injunction was stayed pendingappeal. The Court of Appeals for the Ninth Circuit, in a 2-1 ruling,affirmed the district court's decision May 9, 1999, allowing a facial First Amendment challenge to the CommerceDepartment regulations and holding that the regulations were in fact an impermissible prior restraint. (38) On September 30,1999, the Ninth Circuit granted the United States its motion for a rehearing before the full court of appeals andwithdrewthe earlier opinion. (39) The case was later remandedto the original three-judge panel on January 26, 2000, forreconsideration in light of DOC's new encryption regulations. (40) Plaintiff since requested an advisory opinion from DOCand, in February 2000, the Department reportedly notified him in writing that, under the new regulations, he maypostsource code for his encryption software on his Internet Web site. (41)

The Ninth Circuit three-judge panel had reviewed the district court Bernstein ruling de novo and held that the two-prongtest for facial challenges set forth by the Supreme Court in Lakewood v. Plain Dealer Publishing Co .,486 U.S. 750 (1988),was met. As explained by the court, a licensing scheme is always subject to a facial challenge if, as describedin Lakewood ,it "'gives a government official or agency substantial power to discriminate based on the content or viewpoint ofspeech bysuppressing disfavored speech or disliked speakers,' and has 'a close enough nexus to expression, or to conductcommonlyassociated with expression, to pose a real and substantial threat of ... censorship risks.'" (42) The court held that the firstrequirement was satisfied because the constraint on official discretion contained in the standard used by theCommerceDepartment to deny export licenses under the Export Regulations (EAR) -- namely, inconsistency with "U.S.nationalsecurity and foreign policy interests" (43) -- was, inthe court's view, "little better than no constraint at all." (44) The courtdiscounted government arguments that the scheme was content-neutral, finding that finding that the agency's"boundlessdiscretion" (as it was later described by the court) made DOC's assurances that it would not discriminate on the basisofcontent irrelevant (45)

The second requirement for facial challenges was fulfilled because, in the court's view, the regulations evidenced a "closeenough nexus to expression." The court determined at the outset that "encryption software, in its source code formand asemployed by those in the field of cryptography, must be viewed as expressive for First Amendment purposes, andthus isentitled to the protections of the prior restraint doctrine." (46) The court dismissed the government's argument that, evenadmitting the expressive nature of source code, its functional aspect -- that is, by being compiled into "object code,"it canbe used to control the operations of a computer without conveying information to the user -- obviated FirstAmendmentproblems in this case. (47) It also dismissed thegovernment's argument that because the regulations were "laws of generalapplication" and did not narrowly and specifically target speech, prior restraint analysis did not apply. Again relyingon Lakewood , the court held that the Commerce Department regulations "explicitly apply to expressionand place scientificexpression under the censor's eye on a regular basis," distinguishing them, for example, from a building permitrequirement, which would give officials "only intermittent and unpredictable opportunities" to regulate speech. (48)

The court then held the regulations to be an impermissible prior restraint, finding none of the elements needed to uphold thevalidity of licensing schemes, as set forth by the Supreme Court in Freedman v. Maryland, 380 U.S.541 (1965), to bepresent in this case. As summarized by the court, a licensing scheme that imposed a prior restraint on speech wouldsurvive under Freedman if: (1) any restraint on speech were for a specified period of time; (2) there wasexpeditiousjudicial review; and (3) the censor bore the burden of going to court to suppress the speech and bore the burden ofproof inany such judicial proceeding. (49) The court foundthat the requisite procedural safeguards were lacking because neither theExecutive Branch process for resolving inter-agency disputes over export license applications, nor the internalappealsprocess for license denials contained firm deadlines, and further, the licensing process did not afford judicial reviewtothose whose export license applications were denied. (50)

With respect to the scope of declaratory relief, the government argued that the lower court's order was invalid since itapplied not only to encryption source code, but also to encryption object code, commodities, and technology. Agreeingwith the government that the EAR could be "conceptually severed into component parts covering commodities,softwareand technology," the court nonetheless decided that the "integrated structure"of the regulations did not permit it tosever thejudicially uncontested portions of the regulations and let the lower court relief stand. (51)

The dissenting judge in Bernstein concluded that since the EAR was a law of general application directed at conduct, theplaintiff did not meet the requirements for a facial First Amendment challenge. The dissent emphasized that themajorityand the district court had paid insufficient attention to the functional aspects of encryption. (52) Even though source codecould be used expressively, the dissent argued that it was "inherently a functional device" and that, for purposes ofFirstAmendment analysis, it was nearer to conduct than to speech. (53) Referring to the Ninth Circuit's 1996 decision in Roulettev. City of Seattle , 97 F.3d 300, which had quoted Lakewood , the dissent stated that "such anapproach ignores the basictenet that facial challenges are inappropriate 'unless at a minimum,'" the challenged statute is, in Lakewood's words"directed narrowly and specifically at expression or conduct commonly associated with expression." (54) The dissent foundthat the conduct at issue here was the export of encryption source code, noting that "the overwhelming majority"ofindividuals do not use source code as means of expression but rather as a means of protecting their computercommunications. (55) In such case, "[e]xport ofencryption source code simply does not fall withing the bounds of conductcommonly associated with expression such as picketing or handbilling." (56) The dissent further maintained that the EARregulate encryption technology generally, whether in the form of hardware or software, and as such were directedatpreventing the functional capability of encryption to be exported without a license. (57) In the dissent's view, the fact that theregulations were not directed at expression was supported by the fact that the regulations did not prevent the printpublication of scholarly articles containing source code. (58) While the dissenting judge found that the plaintiff did not meetthe requirements for a facial challenge, he acknowledged that a First Amendment claim with regard to theregulations asapplied may nonetheless succeed in this case. (59)

Karn v. Dep't of State

First Amendment issues also arose in Karn v. Dep't of State , a case brought in the U.S. District Court for the District ofColumbia in which plaintiff challenged the State Department's disapproval of the export of a diskette containingsourcecode for encryption algorithms, while allowing the export of a book containing the same. (60) Along with his FirstAmendment claim, the plaintiff sought judicial review of the State Department's initial designation of the disketteas a"defense article" for purposes of the AECA, and also challenged the regulation on Fifth Amendment due processgrounds. While the court rejected the plaintiff's request for judicial review of the agency's classification decisions, (61) it allowed himto pursue his constitutional claims, though it ultimately dismissed these as well. (62) With regard to First Amendmentarguments, the court held that the diskette was content-neutral and met the First Amendment test applicable togovernmental regulation of such items set forth by the Supreme Court in United States v. O'Brien . Thecourt also rejectedplaintiff's prior restraint argument against the Department's technical data regulations. (63)

In the court's view, the content-neutrality of the AECA regulations was clearly evidenced by the fact that the governmentwas "not regulating the exports of the diskette because of the expressive content of the comments [interspersedthrough thesource code] and or source code, but instead are regulating because of the belief that the combination of encryptionsourcecode on machine readable media will make it easier for foreign intelligence sources to encode theircommunications." (64) As summarized by the court, a challenged regulation will be upheld under O'Brien if "it is within theconstitutional powerof the government, it 'furthers an important or substantial government interest,' and 'the incidental restriction onallegedFirst Amendment freedoms is no greater than is essential to the furtherance of that interest.'" (65)

While the plaintiff did not expressly or impliedly dispute that the first two O'Brien conditions were satisfied, he argued thatthe third element was lacking because, as summarized by the court, "the cryptographic algorithms contained on theKarndiskette are 'already widely available in other countries [through the Internet and other sources] or are so "weak"that theycan be broken by the [National Security Agency].'" (66) The court held that the regulation was in fact narrowly tailored tomeet its goal. Noting that this argument also implicated the second O'Brien requirement, the court heldthat plaintiff'sdisagreement with the government essentially involved a foreign policy dispute and thus "not one into which thisCourt canor will delve." (67) In the court's view, classifyingencryption items as defense articles reflected the President's foreignpolicy judgment that proliferation of encryption products was harmful to the United States, a judgment that existeddespiteany argued availability or capability of the regulated items. (68) The court also rejected the plaintiff's request for judicialbalancing of First Amendment harms against national security interests and found that the plaintiff had not presentedanyarguments that the regulation was substantially broader than was necessary to prevent proliferation of encryptionproducts. (69)

Following issuance of the opinion and the 1996 jurisdictional shift, the plaintiff sought and was denied an export license bythe Department of Commerce. He subsequently pursued his case in the district court, which recently ordered anevidentiaryhearing on his constitutional claims. The hearing is limited to the question whether, for the purposes of producinganoperating encryption system, material differences existed between the plaintiff's diskette and the correspondingsourcecodes appearing in printed form. (70)

Junger v. Daley

A result that conflicted with the Bernstein cases but comported with Karn was reached in the 1998 decision of the U.S.District Court for the Northern District of Ohio in Junger v. Daley , which rejected a First Amendmentchallenge to DOCregulations. (71) In April 2000, the U.S. Court ofAppeals for the Sixth Circuit reversed, holding that computer source codewas protected by the First Amendment, and remanded the case to the district court for consideration of the plaintiff'sconstitutional challenge. (72)

Plaintiff Junger was a law professor who wanted to post encryption programs on his Internet site, an action the DOC treatedas a export. The Department had informed him that he would need export licenses for software programs, but thatachapter in one of his textbooks containing encryption code could be exported without a license. The plaintiff didnot applyfor export licenses for these items, but instead brought a First Amendment challenge to the regulations, claiminga priorrestraint on speech, vagueness and overbreadth, unconstitutional content discrimination, and infringement of rightstofreedom of association and discussion. (73) Thecourt found that source code was "inherently functional" and thus its exportwas not sufficiently communicative to constitute protected conduct under the First Amendment; rejected plaintiff'sfacialchallenges to the DOC regulations on grounds of prior restraint, vagueness and overbreadth; (74) and sustained theregulations under the intermediate First Amendment scrutiny applicable to governmental restrictions deemedcontent-neutral set forth in O'Brien. (75)

On appeal, the Sixth Circuit concluded that "computer source code is an expressive means for the exchange of informationand ideas about computer programming," held that source code thus merited First Amendment protection, andallowed theplaintiff to proceed with his facial challenge of the DOC regulations. (76) The court held out the possibility that intermediateFirst Amendment scrutiny might apply, stating that the functional capabilities of source code should be consideredwhenanalyzing the government's interest in regulating this form of speech, but also noted that in such a case "thegovernment'must demonstrate that the recited harms are real, not merely conjectural, and that the regulation will in fact alleviatetheseharms in a direct and material way.'" (77) While thecourt acknowledged that the government's national security interestsmight outweigh those of protected speech, and require its regulation, it stated that the record to date had not resolvedtheissue in this case. (78) The court allowed the plaintiffto proceed with his constitutional challenge, directing the district courtto examine the new encryption regulations issued in January 2000 to examine whether the plaintiff could bring afacialchallenge on First Amendment grounds.

106th Congress Legislative Proposals

Two bills introduced in the 106th Congress, H.R. 850 and S. 798 ,would have relaxed controlson encryption exports along with addressing other encryption issues. A third bill, S. 854 ,did not expresslyaddress export issues, but had implications for the use of encryption abroad and for government approvals that areconditioned on the use of key escrow or key recovery systems.

H.R. 850 , the Security and Freedom Through Encryption (SAFE) Act, introduced February 25 by Mr.Goodlatte and 204 (later 258) co-sponsors, expanded upon H.R. 695 , a 105th Congress versionof the SAFEAct that had been strongly supported by industry. (79)S. 798 , the Promote Reliable On-Line Transactions toEncourage Commerce and Trade (PROTECT) Act, was introduced April 14, 1999, by Mr. McCain and 5 (later 7)co-sponsors. Mr. McCain had sponsored an encryption bill in the 105th Congress ( S. 909 ) thatsought to relaxencryption export controls, but would have given the executive branch greater leeway to impose restrictions thanwould bepossible under S. 798 . The Clinton Administration had opposed the introduced version of H.R. 695 , but generally favored H.R. 909 . While both H.R. 850 and S. 798 weresupported by industry, the Clinton Administration stated its opposition to each. (80)

H.R. 850 was reported by the House Judiciary Committee, the House Commerce Committee, the House International Relations Committee, the House Armed Service Committee, and the House Permanent SelectCommittee onIntelligence, resulting in differing versions of the bill, two of which would allow strict export controls on encryption. TheHouse Rules Committee was to determine which version of the bill would be presented for floor action. S. 798 was ordered reported favorably and without amendment June 23 by the Senate Commerce Committee, the onlycommittee to which the bill was referred.

No further action was taken on any of these bills.

H.R. 850, as Introduced and Reported

H.R. 850 , as introduced, would have amended the Export Administration Act of 1979 to grant the Secretary ofCommerce sole authority over nonmilitary encryption. After a one-time 15-day technical review (meaning a reviewtodetermine that the item works as represented), the Secretary could no longer have required an export license for awidevariety of encryption hardware and software, except pursuant to the Trading with the Enemy Act (TWEA) orIEEPA. TheSecretary would also have been required, after a one-time 15-day technical review, to permit the export of strongencryption for nonmilitary end uses (1) in countries to which certain financially-related encryption could then beexported,unless there was substantial evidence that the item would be diverted to a military end use or an end use supportinginternational terrorism, modified for military or terrorist end use, or reexported without any U.S. authorization thatmightbe required under the EAA, or (2) if he determined that comparable encryption was commercially available abroadfrom aforeign supplier without effective restrictions. The Secretary could not have reinstated export controls on encryptionitemsthat were decontrolled as of the date of enactment, but could have prohibited the export of specific encryptionproducts toan individual or organization in a specific foreign country if there was substantial evidence that the item wasdestined forterrorist or military end-uses. In addition, the President would have been allowed to prohibit the export of encryptionproducts to terrorist countries or as part of an embargo under the IEEPA, the Trading with the Enemy Act (TWEA)or theEAA.

Regarding the sale and use of encryption generally, the bill would have, among other things, made it lawful for any U.S.person in a foreign country to use any encryption, regardless of the encryption algorithm selected, encryption keylengthchosen, or implementation technique or medium used, excepting encryption activities undertaken in the commissionof afelony under a U.S. criminal statute. A U.S. person would have included a U.S. citizen, a U.S. firm, and a foreignfirmowned or controlled by U.S. citizens or firms. The bill would have also prohibited the Federal Government fromrequiringkey escrow capabilities in encryption products or conditioning any approval on the existence of such capabilities.

The House Judiciary Committee , which did not address export issues, reported the bill April 27 ( H.Rept. 106-117 , Part1). The House Commerce Committee reported the bill as amended July 2 ( H.Rept. 106-117 , Part2). The CommerceCommittee version added provisions that would have required the Assistant Secretary of Commerce forCommunicationsand Information and the National Telecommunications and Information Administration (NTIA) to issue regulationswithin90 days of enactment identifying which products under DOC jurisdiction were designed for improvement of networksecurity, network reliability, or data security ("critical infrastructure protection products"). Regarding products soidentified, it would have also delegated to these agencies by 2 years after enactment all authority regarding exportdeterminations and technical reviews that the Act delegated to the Secretary. The amended version would have alsoexpanded the 15-day technical review periods to 30 "working days"; required DOC to consult with the SecretariesofDefense and State, the Attorney General, and the Director of Central Intelligence before the licensing policiesprovided forin the bill took effect; allowed DOC to prohibit exports of strong encryption and specific encryption products to endusersin specific countries for the additional reasons of harm to U.S. national security, use in sexual exploitation ofminors, or usein illegal activities involving organized crime; and provided that encryption products could be controlled for anyreasonother than their encryption capability and that nothing in the SAFE Act or its amendment of the EAA altered theability ofthe Secretary of Commerce to control exports for reasons other than encryption.

This version also added provisions that would have created a National Electronic Technologies Center to assist lawenforcement in developing and maintaining encryption capabilities; required the Secretary of Commerce toundertakeexport promotion activities for encryption products; directed the President to begin negotiating internationalagreements tofacilitate encryption trade and provide for mutual recognition of countries' export controls (allowing the Presidenttoconsider a country's refusal to negotiate when considering U.S. participation in any cooperation or assistanceprogram withthat country); and criminalized transfers of over 56-bit encryption products to the People's Liberation Army andothermilitary end users in the People's Republic of China (PRC).

The House Committee on International Relations reported the bill as amended July 19, 1999 ( H.Rept. 106-117 , Part 3). This reported version would have, among other things, expanded the 15-day technical review periods to 30 "workingdays";required DOC to consult with the Secretaries of Defense and State, the Attorney General, and the Director of CentralIntelligence before the licensing policies provided for in the bill took effect; required the Secretary, before approvinganencryption export or re-export to a major drug-transit country or major illicit drug-producing country, to consult withtheAttorney General, the FBI Director, and the Administrator of the Drug Enforcement Administration regarding theimpact ofthe export or re-export on the flow of illicit drugs into the United States (but would not have authorized theprohibition ofan export or a license denial solely because the destination was one of these countries); and provided that nothingin theSAFE Act limited the President's authority under IEEPA, TWEA, or the EAA, to prohibit the export or reexportof over56-bit encryption to any PRC military unit.

The amended bill would have also expanded the reasons for which the Secretary could make specific export denials byadding the facilitation of illicit drug imports into the United States, the manufacture of weapons of mass destructionorassistance in the proliferation of such weapons, and illegal activities involving sexual exploitation of minors;required theSecretary to consult with the Secretaries of Defense and State, the Attorney General, the FBI Director, theAdministrator ofthe Drug Enforcement Administration, and the Director of Central Intelligence before making such decisions; andchangedthe evidentiary standard for such decisions from "substantial" to "credible. The committee version also providedthatencryption products would be subject to export controls imposed for any reason other than their encryptioncapability(including export controls imposed on high performance computers) and that nothing in the SAFE Act or itsamendment ofthe EAA altered the ability of the Secretary of Commerce to control exports for reasons other than encryptioncapabilities.

The House Committee on Armed Services reported a rewritten version of H.R. 850 on July 21 in the form ofan amendment in the nature of a substitute ( H.Rept. 106-117 , Part 4). (81) The amendment, which did not address thedomestic sale or use of encryption, would have renamed the bill the "Protection of National Security and PublicSafetyAct"; given the President sole authority to control the export of all dual-use encryption products; authorized thePresident todeny the export of any encryption product on the basis that its export is contrary to U.S. national security interests;and prohibited judicial review of any presidential or presidentially-delegated encryption export decision under the Act.

The amendment would have allowed the export of encryption under licenses and license exceptions depending onencryption strength. The President would have been required to notify Congress, within 180 days of enactment, ofthemaximum level of encryption strength that could be exported under a license exception without harm to U.S.nationalsecurity interests. It would have made an encryption product that did not exceed this level eligible for an exportlicenseexception, provided (1) the product was submitted for a one-time technical review (with required information tobedetermined by the President); (2) the item did not require licensing under otherwise applicable regulations; (3) theitem wasnot intended for a country, end user, or end use that was by regulation ineligible to receive the product and theencryptionwas otherwise qualified for export; and (4) the exporter, at the time the product was submitted for technical review,provided the names and addresses of its distribution chain partners. After his initial notification, the Presidentwould havebeen required to continue to inform Congress of the encryption strength for license exceptions every subsequent 180days,and could no longer decrease this level.

A license would have been required for the export of any encryption products designed or manufactured within the UnitedStates with an encryption strength that exceeded the license-exception level. The license applicant would haveneeded tosubmit the product for technical review, to certify the intended end use and expected end user of the product, toprovideinformation regarding a distribution chain partner if the export was being made to such an entity, and to submit anyotherinformation required by the President. The amendment would also have required post-export reporting by anexporter whohad reason to believe that an exported product was diverted to unauthorized end uses or end users, and required allexporters and distribution chain partners of such exporters to submit a report to the Secretary specifying theparticularproduct sold, the name and address of the end user of the product, and the intended end use of the product.

This committee amendment would have authorized the President to waive provisions regarding license exceptions if hedetermined that the waiver was necessary to protect U.S. national security interests and reported to Congressregarding anysuch waiver. It would also have authorized the President to waive the licensing requirement for stronger encryptionforspecific classes of end users identified as being eligible for receipt of encryption commodities and software underthecurrent license exception for encryption in 15 C.F.R. ï¿½ 740.17, and required him to report to Congress on any suchwaiver. The committee amendment would also have created a public-private Encryption Industry and Information SecurityBoard toadvise the President on the foreign availability of encryption products and required the Secretary of Commerce toconduct amarket share survey of foreign markets for encryption products at least once every 6 months.

The House Permanent Select Committee on Intelligence July 23 reported an amendment to H.R. 850 in thenature of a substitute, retitling the bill the Encryption for the National Interest Act ( H.Rept. 106-117 , Part 5). Withregardto general export authorities, this version, similar to that reported by the House Armed Services Committeeamendment,would have given the President sole authority to control the export of all dual-use encryption products; authorizedthePresident to deny the export of any encryption product on the basis that its export was contrary to U.S. nationalsecurityinterests; and prohibited judicial review of any presidential or presidentially-delegated encryption export decisionunder theAct based on national security.

The amendment would also have required a system of export licenses and license exceptions. An encryption product of 64bits or less would have been eligible for a license exception, provided (1) the product was submitted for a one-timetechnical review (a maximum 45-day process with required information to be determined by the President); (2) theitem didnot require licensing under otherwise applicable regulations; (3) the item was not intended for a country, end user,or enduse that was by regulation ineligible to receive the product and the encryption was otherwise qualified for export;(4) theexporter, within 180 days after export, submitted a certification identifying the intended end use of the products andthename and address of the intended recipient, if available; (5) the exporter, within 180 days after export, provided thenamesand addresses of its distribution chain partners; and (6) the exporter, at the time the product was submitted fortechnicalreview, provided proof that its distribution chain partners had contractually agreed to abide by all U.S. laws andregulationsinvolving the export or reexport of U.S.-origin encryption products. It would also have allowed license exceptionsfor theexport of an encryption product whether or not the product contained a method of decrypting encrypted data. (82) Thecommittee version would have required the President periodically to review the encryption strength that could beexportedunder the license exception without harm to U.S. national security, but would not have allowed him to reduce thelevelfrom 64 bits.

The amendment would have allowed the President to grant a license for the export of any encryption product designed ormanufactured within the United States with an encryption strength that exceeded the license-exception level underthefollowing conditions: (1) a requirement that the product contain a method of gaining timely access to plaintext ordecryption information may not be imposed as a condition of the license; (2) the products must be submitted fortechnicalreview; (3) the exporter must submit a certification identifying the intended end use and the expected end user orclass orend users of the product; (4) the exporter must provide proof that its distribution chain partners have contractuallyagreed toabide by all U.S. laws and regulations involving the export and reexport of U.S.-origin encryption products; and (5)theexporter must submit the names and addresses of the distribution chain. The bill also provided for post-exportreporting bythe exporter of possible unauthorized diversions, pirating, and encryption sales by distribution chain partners.Notwithstanding the provision for licenses, the President would have been permitted to allow exports under a licenseexception for higher level encryption if the export was consistent with national security.

The amended version would also have required the President to provide for expedited review of commodity classificationrequests and export license applications involving encryption items; allowed the Secretary of Commerce, theSecretary ofDefense and the Secretary of State to use their existing statutory authorities to carry out the export provisions of thebill;and granted the President judicially unreviewable authority to waive the bill's export requirements if he determinedthat thewaiver was "necessary to advance the national security."

The committee amendment would have created a public-private Encryption Industry and Information Security Board toadvise the President on a variety of issues involving encryption, including the benefits and risks ofglobally-distributedstrong encryption, the advancement of international standards for encryption products, and availability and marketshare offoreign encryption and their threat to U.S. industry. It also contained a sense of the Congress provision exhortingthePresident to negotiate international agreements establishing binding export control requirements on strongnonrecoverableencryption products that safeguard the privacy of U.S. citizens, prevent economic espionage, and enhance U.S.informationsecurity needs, and allowed the President to consider a country's refusal to negotiate such agreements whenconsideringU.S. participation in any cooperation or assistance program with that country.

In addition, this committee bill addressed the domestic use of encryption, government procurement, and liability limitationsfor persons disclosing or providing plaintext of encrypted data, decryption information, or technical assistance.

S. 798, as Introduced and Reported

S.. 798, as introduced April 14, 1999 and reported, would have granted the Secretary of Commerce sole authority overnonmilitary encryption exports, requiring him to exercise his authority in consultation with the Secretaries ofDefense andState. It would have allowed the President to use his TWEA and IEEPA authorities (1) to prohibit the export ofencryptionto a country, corporation, or other entity determined to support terrorism or to pose an immediate threat to nationalsecurityand (2) to impose a trade embargo with respect to a specific country, corporation or entity. The Secretary ofCommercecould also have prohibited the export of particular encryption to particular foreign individuals or organizations ifthere wassubstantial evidence that the encryption might be used or modified for military or terrorist use. Export controls onencryption would also have been allowed if the control was imposed for reasons other than encryption capability.

The bill would have decontrolled encryption of up to 64 bits and required license exceptions for recoverable products,encryption destined for certain commercial end-users and governments of NATO, OECD, and ASEAN countries,technology with interface mechanisms, and related technical assistance or data. Products would have been eligiblefor anexception after a one-time technical review; the request for the exception (including the review) was to be completedwithin 15 working days. The bill would also have permitted exports of stronger encryption under a licenseexception if theSecretary of Commerce determined that the product was exportable under the EAA or a new public-privateEncryptionExport Advisory Board determined (and the Secretary agreed) that such products were generally or publiclyavailable, or acomparable product would soon be available abroad (subject to presidential override on national security grounds). Whilea decision by the Secretary to disapprove an availability finding by the advisory board would have been subject tojudicialreview, a presidential national security override would not have been. A technical review and 15-day processingperiodwould also have applied to these items. In addition, DOC license approvals for over 64-bit encryption would havebeengrandfathered.

The bill would have directed the National Institute of Standards and Technology to adopt an Advanced EncryptionStandard by January 1, 2002, after which time the Secretary of Commerce could no longer impose encryption exportcontrols on items that incorporated the new standard or an equivalent. These goods would be exportable withoutrestrictions, except for those restrictions permitted under the bill. The bill would also have prohibited the SecretaryofCommerce from taking actions that had the effect of imposing government-designed encryption standards on theprivatesector by restricting encryption exports and from imposing any reporting requirements on encryption products thatwere notsubject to export controls or license exceptions.

S. 798 also contained provisions regarding the domestic use of encryption, government procurement, thedevelopment of the Advanced Encryption Standard (in addition those described above), and the improvement ofthegovernment's technological capability.

S. 864, as Introduced

While not primarily focused on export controls, S. 854 , the Electronic Rights for the 21st Century Act,introduced April 21 by Mr. Leahy and referred to the Senate Committee on the Judiciary, would have made it lawfulforany U.S. person in a foreign country to use, develop, manufacture, sell, distribute, or import any encryption product,regardless of the encryption algorithm selected, encryption key length chosen, existence of key recovery or otherplaintextaccess capability, or implementation or medium used (ï¿½ 201(a)). It would also have generally prohibitedgovernment-mandated key escrow or key recovery by not allowing any U.S. agency, among other things, to"condition anyapproval" on certain requirements involving a decryption key, access to a decryption key, key recovery information,orother plaintext access capability (ï¿½ 201(b)).