WRITTEN SUBMISSION OF MR. HUGH DANIEL IN THE MATTER OF APL9800007/Z066051/G006298 QUESTION PRESENTED The Bureau of Export Administration ("BXA") classified appellant's software as authentication software exempt from encryption item ("EI") controls under a published rule that is part of the Export Administration Regulations ("EAR"). Appellant then published his software so that, by law, it was not subject to the EAR at all. Almost a year later, in a second adjudication triggered by an unrelated party's litigation claim, BXA used a significantly different, unpublished rule, reversed the first order, imposed EI controls on the software, and warned appellant that continued publishing would be unlawful, without giving him timely notice or an opportunity to be heard. Did BXA act unlawfully? INTRODUCTION Appellant Mr. Hugh Daniel contends that BXA's original classification of his program, Integrated DNSSEC ("the Software"), was correct and its reclassification incorrect. The original classification followed the published rule exempting authentication software from EI controls.1 This legally binding rule defines authentication software based on its function and includes software containing encryption, so long as the software only uses encryption as needed for authentication. In contrast, the reclassification was legally invalid, because BXA used an unpublished legislative rule that significantly departs from the published rule without providing any meaningful explanation. "[A]n agency changing its course by rescinding a rule is obligated to supply a reasoned analysis for the change beyond that which may be required when an agency does not act in the first instance."2 Furthermore, BXA's restraining appellant's continued publication of the Software in source code form implicates the First Amendment. Because the Commerce Department ("DOC") contests this position in litigation, and because there are ample nonconstitutional grounds for reversal, appellant has not previously pressed this point. But it must be raised here, given the suggestion made at the informal hearing that the Undersecretary is committed to finding BXA's reclassification valid. Courts are to "hold unlawful and set aside" agency action that is "arbitrary, capricious, an abuse of discretion, or otherwise not in accordance with law"3 under the Administrative Procedure Act ("APA"). BXA's actions in this matter are unlawful under any of these formulations, and the Undersecretary should avoid judicial review by reversing them.4 Factual and procedural background Appellant submitted a commodity classification request for the Software to BXA on or about April 1997. The request included, among other things, a cover letter and a floppy disk containing the Software in source code form, including the RSAREF encryption toolkit ("RSAREF"). Appellant stated that the Software only used RSAREF for authentication. BXA classified the Software as EAR99. Software so classified is subject to BXA controls; however, EAR also provides that such software may be made publicly available, and thus "not subject to the EAR."5 In reliance on the classification and the public availability provision, the Software was published on the Internet to all persons worldwide. On June 19, 1998, appellant's counsel received a letter from Mr. James Lewis of BXA ("Lewis letter") stating that BXA had withdrawn the EAR99 classification and reclassified the Software as 5D0026 "because it includes the source code for RSAREF, which can be used not only to encrypt files for authentication but, with minimal effort, to also encrypt data for confidentiality purposes." The letter warned that continued publication of the Software "without any precautions to prevent its unauthorized transfer outside the United States" would be an unlawful export. Appellant stopped publishing. Appellant then learned that the Software's reclassification had probably been triggered by ongoing litigation in Karn v. U.S. Department of State, et al., Civ. A. No. 95-1812-LFO (D.D.C.). The plaintiff argued that BXA had acted inconsistently in classifying his diskette as 5D002 but classifying the Software as EAR99 when both items contained RSAREF. Mr. Lewis submitted a declaration to the court indicating that the Software's reclassification was a response to Mr. Karn's claim. Declaration of Mr. James Lewis, para. 4 (June 19, 1998) ("Lewis Decl."). By letter dated June 30, 1998, appellant appealed BXA's reclassification to the Undersecretary and requested an informal hearing. This written submission is authorized by the Undersecretary as part of the appeal, and incorporates by reference all documents submitted in connection with the Software's original classification and reclassification. ARGUMENT At issue are two BXA actions: the Software's reclassification and BXA's attempt to promulgate a new authentication exemption in that adjudication. Appellant advances four theories under which the reclassification was unlawful. First, BXA lacks jurisdiction to reclassify the Software because, now that it has been published, it is no longer "subject to the EAR." Second, even if BXA has residual jurisdiction over the Software, it lacks authority to impose EI controls on authentication items. EI controls are only authorized for encryption items transferred to DOC jurisdiction before Nov. 15, 1996, and DOC acquired jurisdiction over authentication items in 1992. Third, BXA unlawfully used a new, unpublished rule to reclassify the Software. Under the published rule, authentication items that contain encryption are not subject to EI controls when they do not encrypt for confidentiality. The Software, however, was reclassified because it could be modified "with minimal effort[] to also encrypt data for confidentiality purposes." This factor is not in the published rule. Fourth, BXA violated appellant's due process rights in several ways. In particular, appellant was not afforded a pre-deprivation hearing before reclassifying the Software. Appellant also challenges the new rule on its face. As enunciated by BXA, the new rule lacks objective content and fails to provide: fair notice to regulated persons; objective guidelines to constrain the discretion of BXA officials; meaningful standards for judicial review. It is therefore facially invalid for vagueness, or, in administrative law terms, for arbitrariness. Significant here is BXA's failure to explain or justify its attempted shift to a new rule. BXA identified no problems with the published rule, made no agency record in support of the new rule, and stated no reasons for the new rule. It did not explain how the new rule was applied to appellant's Software. Such failures render invalid BXA's attempt to promulgate a new rule. Appellant makes two additional arguments. As a policy matter, there is a strong public interest in DNS authentication, which is supported by, and supports BXA's continuing to follow, the published rule. As a legal matter, BXA's actions are subject to judicial review because the present statutory basis for EAR, the International Economic Emergency Powers Act ("IEEPA"), does not preclude judicial review. I. BXA could not reclassify the Software because it is not subject to the EAR. The phrase "subject to the EAR" "describe[s] those items and activities over which BXA exercises regulatory jurisdiction under the EAR. . . . Conversely, items and activities that are not subject to the EAR are outside the regulatory jurisdiction of the EAR and are not affected by these regulations."7 Software that is or will be made publicly available is not "subject to the EAR,"8 except for encryption software under EI controls. When BXA held that the Software was EAR99 and thus not under EI controls, appellant became free to make it publicly available, which he did.9 At that point, BXA lost jurisdiction to regulate the Software.10 This conclusion is buttressed by the principle that "[r]etroactivity is not favored in the law."11 "[A]dministrative rules will not be construed to have retroactive effect unless their language requires this result," and "[b]y the same principle, a statutory grant of legislative rulemaking authority will not, as a general matter, be understood to encompass the power to promulgate retroactive rules unless that power is conveyed by Congress in express terms."12 Appellant is unaware of any such conveyance in IEEPA. Appellant's publishing the Software had the legal effect of making the Software not "subject to the EAR." BXA sought to change that legal effect after it occurred, which amounts to "attach[ing] new legal consequences to events completed before its enactment"13 or "altering the past legal consequence[] of past actions."14 "[F]amiliar considerations of fair notice, reasonable reliance, and settled expectations"15 demand that appellant be protected against such regulatory overreaching. II. BXA has no legal authority to impose EI controls on the Software. A. Only encryption items transferred to DOC pursuant to E.O. 13026 are subject to EI controls; authentication items were transferred earlier. The EI reason for control "applies only to encryption items transferred from the U.S. Munitions List to the Commerce Control List consistent with E.O. 13026 of November 15, 1996."16 Jurisdiction over authentication items, however, was transferred in 1992 via amendments to the International Traffic in Arms Regulations ("ITAR").17 Indeed, BXA specifically stated that "[e]ncryption items transferred from the USML to the CCL prior to November 15, 1996 are not controlled for EI reasons."18 There is no meaningful difference between the description of authentication items then transferred and their description under EAR. The "data authentication" exemption, which BXA apparently relied on initially, is essentially unchanged. The ITAR rule transferring jurisdiction over authentication used the language, "[l]imited to data authentication . . . to ensure no alteration of text has taken place, or to authenticate users, but does not allow for encryption of data, text or other media other than that needed for authentication."19 The comparable EAR provision reads: "Data authentication . . . to ensure no alteration of text has taken place, or to authenticate users, but does not allow for encryption of data, text or other media other than that needed for authentication."20 Because authentication items were not transferred by the Nov. 1996 Executive Order, EI controls cannot apply to them.21 B. The Software is exempt from EI controls under a clear legislative rule. Under EAR, the difference between encryption items and authentication items lies in what they do. Authentication items are not encryption items because they do not encrypt for confidentiality. As noted above, the distinction between encryption and authentication has existed since at least 1992, a long time in this rapidly changing area. 1. Encryption and authentication items are defined by what they do. The regulations refer to whether software functions to encrypt for confidentiality. EI controls are imposed "on certain information security systems and equipment, cryptographic devices, software and components specifically designed or modified therefor, and related technology ('encryption items')."22 5D002.a "controls 'software' designed or modified to use 'cryptography' . . . to ensure 'information security.'"23 The phrase "designed or modified" is significant because it defines the scope of control over items based on what they do - as they are designed.24 "Encryption software is controlled because . . . it has a functional capacity to encrypt information on a computer system."25 Authentication items are specifically exempt from EI controls, and they too are defined by what they do. Software designed to authenticate is exempt from EI controls even if it contains encryption, so long as it uses the encryption only as needed for authentication. In short, encryption items are designed to encrypt for confidentiality; authentication items are designed to authenticate. What matters is what items do. 2. The Software is exempt from EI controls because it authenticates and does not use encryption other than for authentication. Authentication software may contain encryption so long as the encryption is used for authentication rather than for message confidentiality. In this section appellant explains why authentication software generally contains encryption and why authentication for the Internet's Domain Name System ("DNS") requires encryption. Encryption is often associated with message confidentiality, but is also used for the important purpose of authentication. Authentication provides a way to prove the "authenticity" of a message; it is a general category of technology that guards against such threats as forgery or fraud. The use of a login-name and password to control access to a computer is a simple example. Mathematical authentication replaces ordinary human techniques like handwritten signatures, facial recognition, or passwords, which are trivial to forge from the other end of a communications link (e.g., by replaying stored copies of the real signature, face, or password). Authentication applications use cryptography in two main ways. Most fundamentally, they rely on the same mathematical principles and techniques that are used for confidentiality. Second, authentication often requires that long-term secrets (such as passwords or keys) be stored securely, which requires the use of encryption.26 Public-key authentication permits any party to check the authenticity of a message. It involves "signing" a plaintext message by appending a signature computed from the message and a secret key. The message's authenticity is checked by using a matching published key to extract the signature and compare it to the contents of the message. Such a system's security relies on the mathematical difficulty of forging a signature when the secret key is unknown to the forger. Public-key confidentiality protocols use the same operations, but on slightly different numbers. A secret message can, for example, be sent by computing a function of the message and the recipient's published key; it can then be read by combining the message and the matching secret key. Appellant's classification request clearly explained how the Software uses encryption for authentication, not confidentiality; those technical details will not be repeated here. Appellant emphasizes, however, that the Software's use of encryption for authentication is absolutely necessary for the particular purpose for which the Software was designed - preventing forgery or other malicious interference with the operation of the Internet's DNS. The DNS is a critical part of the Internet infrastructure that defines the meaning of names on the Internet, such as "bxa.doc.gov" (referred to as "domain names"). It does so by maintaining a database (not unlike a phone directory), containing every valid name on the Internet and its associated information (such as the numeric address of the computer with that name). When you click a link in a Web page or type in a URL, your browser looks up the URL's domain name in the DNS, then contacts the machine at the matching numeric address to fetch the new Web page. The DNS lookup usually takes a fraction of a second and is invisible to the user. Much of the DNS's complexity stems from its being a global, distributed, replicated, dynamic database. The design emphasizes high reliability and scalability, and has survived intact through twenty years of tremendous Internet growth. Responsibility for keeping the data associated with each name is delegated to the name's owner. Looking up that data can involve sending queries to several different parts of the Internet, gradually homing in on its location. Each datum is stored on at least two computers in different places for reliability, and can also be "cached" (temporarily replicated) anywhere else in the system for higher speed and reliability. A set of high-reliability servers distributed around the world provide duplicate authentic copies of the "root zone," which describes the location of the few hundred top-level domains (such as ".com" or ".us"). An entire copy of the database is never stored or collected in a single location. Unfortunately, the DNS designed twenty years ago is insecure. There is no mechanism for verifying the authenticity of the DNS database. Someone can insert false information into the DNS, and the DNS has no way of knowing that it is false. A forger can, for example, substitute DNS information so that requests addressed to "www.bxa.doc.gov" go elsewhere. More insidiously, he or she could redirect such Web accesses to another location, but have that location then forward them back to the true "www.bxa.doc.gov" in real time. The forger would then have invisible access to watch or alter the transactions going to and from the true site. It is not possible to protect the DNS database by out-of-band authentication techniques the way a telephone company protects the reliability of its phone directories. Because responsibility for the data is distributed, no one party can verify the entire DNS database; authentication of the data for a given name must be done by the name's owner. DNS lookups are done by millions of computers, automatically, as part of their everyday operation. Because the authentication must be checked at many locations distant from where the data is stored, any DNS authentication must be automatic; public-key cryptographic techniques must be used. For these reasons, the Internet Engineering Task Force ("IETF"), the organization that establishes all of the official Internet standards, generated technical specifications ("the DNS Security Extensions") for incorporating digital authentication into the DNS. They do not provide for message confidentiality; their function is to provide for the publication and validation of authenticated data already stored in the DNS structure. In layman's terms, successful implementation of the DNS Security Extensions would mean that all information in the DNS database would be digitally signed. A DNS server configured in accordance with the DNS Security Extensions can authenticate the origin and integrity of information received through a DNS exchange.27 The Software implements the DNS Security Extensions using a cryptographic library called RSAREF. The Software does not provide for any message confidentiality, but its underlying mathematics can be used to provide message confidentiality if someone modifies RSAREF to operate on different data. Any such modification to Integrated DNSSEC, however, would render it incompatible with every other DNS implementation (and thus useless); the DNS protocol and the DNS Security Extensions do not provide for or contemplate message confidentiality. RSAREF, the encryption "inside" Integrated DNSSEC, is not a cryptographic application; it is not an application at all. It is not as though RSAREF could, once removed, be run on a computer by itself to encrypt for confidentiality. RSAREF is a library of cryptographic techniques or subroutines that a programmer could use to write an application. BXA appears to be afraid that some foreign entity will remove RSAREF from Integrated DNSSEC and write a completely independent cryptographic application using it.28 This risk cannot be eliminated, because in public-key cryptography, the same mathematics are used for both authentication and encryption; an authentication application using public-key cryptographic techniques necessarily contains cryptographic subroutines that can be used for message confidentiality.29 3. BXA admitted that the Software is authentication software under the published rule. BXA's letter and declaration implicitly concede that the Software as submitted by appellant only authenticates and does not use encryption beyond that needed for authentication. The Lewis letter states that the EAR99 classification was based on BXA's "understanding that the program could only be used to authenticate users or messages," but that the 5D002 reclassification is proper "because [the Software] includes the source code for RSAREF, which can be used not only to encrypt files for authentication but, with minimal effort, to also encrypt data for confidentiality purposes." BXA's declaration is to the same effect. The EAR99 classification was "based on what BXA understood the application of the product to be, that the RSAREF toolkit was only used in Integrated DNSSEC to authenticate users or messages."30 On reclassification, "BXA determined that, while the RSAREF is used in Integrated DNSSEC to authenticate users or messages, the software also included the source code for RSAREF. That source code can be used . . . with minimal programming effort, to encrypt data for confidentiality purposes."31 BXA never states that the Software as submitted does anything but authenticate or that it can be used to encrypt for confidentiality. It never states that RSAREF can by itself be used to encrypt for confidentiality. In short, BXA did not state that the Software encrypts for confidentiality, and BXA presumably would have if it could have.32 Thus, it is clear from BXA's own statements that the Software, as submitted, falls within the plain meaning of the published rule because it authenticates and does not encrypt data for confidentiality purposes. 4. This rule is a legislative rule that binds BXA.33 A fundamental principle of administrative law is that an agency must follow its own rules until they are validly amended or rescinded, even if it had no duty to adopt the rules in the first place.34 BXA is bound by the published rule exempting authentication items from EI controls until it validly promulgates a new rule. Even if BXA now publishes the new rule and rescinds the old rule, that would not validate the Software's reclassification.35 III. The Software's reclassification violated due process. A. Appellant has a protected Fifth Amendment interest in being able to publish the Software. Appellant acquired a Fifth Amendment interest by virtue of his publishing the Software pursuant to BXA's EAR99 classification, so that it was not "subject to the EAR." As a result, he acquired a "legitimate claim of entitlement" to continue publishing it, "created and . . . defined by existing rules . . . that stem from an independent source"36 - EAR itself. At that point he had a property interest in free dissemination of the Software, the purpose stated in his classification request.37 Here, the value of the Software to appellant lies primarily in his being able to publish it freely. Appellant's right to continue publishing the Software in source code form is also a protected liberty interest under the First Amendment.38 Fifth Amendment due process requires that the intentional deprivation of so important an interest be conducted pursuant to a pre-deprivation hearing.39 Appellant did not receive fair notice of the reclassification of his Software under BXA's new rule. Fair notice is lacking unless a regulated party acting in good faith is able to identify the proper standard "with ascertainable certainty" on the face of the published rules.40 BXA's reclassification without notice is much like "us[ing] a citation as the initial means of announcing a particular interpretation," which raises issues of "the adequacy of notice to regulated parties."41 B. The reclassification occurred without notice to appellant and deprived him of a pre-termination hearing. Moreover, agency rules and other statements that affect members of the general public, and changes thereof, must be published.42 No person may be adversely affected "in any manner" by a rule required to be and not so published, except to the extent that the person has actual and timely notice of the terms.43 BXA's new rule is "of general applicability." It does not merely relate to how BXA will exercise its discretion; it purports to define what items are not subject to EI controls. Appellant was adversely affected by the reclassification the moment it occurred, and as argued below, the rule used and announced in the reclassification changed the existing exemption. To appellant's knowledge, however, neither BXA's declaration nor letter was published. Thus appellant could not have had his Software reclassified, because BXA did not publish its new rule.44 Also, appellant was entitled to an opportunity to defend the original classification within the reclassification review, i.e., a pre-deprivation hearing. Under the APA, he can be characterized as having had a "license" to publish the Software once it was classified EAR99. "[A] license with reference to an activity of a continuing nature does not expire until the application has been finally determined by the agency."45 BXA's reclassification withdrew, revoked or annulled that "license." Such action is lawful "only if, before the institution of agency proceedings therefor," the licensee has been given notice and an opportunity to demonstrate or achieve compliance with all lawful requirements.46 Finally, because BXA reclassified the Software without affording appellant due process, appellant must now seek reversal of BXA's decision after the fact. But "the proponent of a rule or order has the burden of proof."47 BXA's original EAR99 classification and reclassification each were orders. As proponent of the new order, BXA has the burden of proof, not appellant. For BXA to apply its stated rule, BXA must at least show that the Software could as a factual matter be easily modified to encrypt for confidentiality. BXA presented no evidence on this score; it merely asserted ease of modifiability. Thus, it has failed to meet its burden. C. The reclassification may have been motivated by an improper desire to preserve a litigation position to appellant's detriment. As noted earlier, the circumstances of the reclassification strongly suggest that it was motivated by a desire to preserve the government's position in litigation with another party in a wholly unrelated matter. If so, BXA abused its discretion by adversely affecting appellant simply to improve or maintain a position in litigation to which he is not a party.48 Moreover, an agency position first advanced in litigation is owed significantly less deference, if any, by a court.49 "[I]t is likely that 'a position established only in litigation may have been developed hastily, or under special pressure,' and is not the result of the agency's deliberative processes."50 IV. The Software's reclassification was ultra vires. That BXA initially classified the Software as EAR99 puts the burden of proof on BXA to explain why it changed its mind. "It is a maxim of administrative law that: 'If a second rule repudiates or is irreconcilable with [a prior legislative rule], the second rule must be an amendment of the first; and, of course, an amendment to a legislative rule must itself be legislative.'"51 BXA applied a rule significantly different from the published rule. But there is no evident agency record as to difficulties with the old rule, and BXA offers no justification for its new rule. BXA therefore exceeded its authority. A. The Software's reclassification rested on a rule substantially different from and plainly inconsistent with the published rule. The regulatory text imposing EI controls refers to whether software is "designed or modified" to encrypt for confidentiality. The published authentication exemption uses two factors: whether the software authenticates; whether, if the software uses encryption for authentication, that encryption is limited to that needed for authentication. It asks, in short, whether software is designed for authentication. BXA reclassified the Software because it includes the source code for RSAREF, which BXA asserted could "with minimal effort" or "with minimal programming effort" be used to encrypt for confidentiality.52 BXA in essence stated that the criterion for imposing EI controls on the Software is that the Software can be easily modified to encrypt for confidentiality. This criterion is not in the black-letter rule, and adding it to the published exemption significantly changes it. First, as a textual and as a semantic matter, there is an enormous difference between that which is designed to do something, and that which can be modified to do something. The former focuses on the item as it is; the latter, on the item as it could be.53 As appellant showed earlier, the published rules focus on items as they are designed. This same principle underlies the allocation of export jurisdiction between the State Department and DOC: "encryption items specifically designed, developed, configured, adapted or modified for military applications . . . are controlled by [State] on the U.S. Munitions List."54 The State Department does not control items that could be modified to be used for military applications; it controls items that are already modified for military applications. Second, the published rule by its terms recognizes that authentication software may contain encryption without being subject to EI controls. It not only recognizes the mathematical reality that authentication uses encryption techniques, but embodies a policy that resolves the potential tension between controlling encryption and decontrolling authentication. That policy recognizes the benefits of freely publishable authentication software by accepting the risk that authentication software containing encryption may be modifed and used for confidentiality. The new rule defines items differently. Instead of asking what the software does as written, it asks whether someone could rewrite the software to make it encrypt for confidentiality. It also changes the aforementioned policy: it does not accept the risk that authentication software containing encryption may be modified and used for confidentiality. BXA's new rule is thus a major change in both meaning and policy.55 B. The Software's reclassification was not supported by substantial evidence. BXA had the burden of proof in reclassifying the Software, and courts shall hold unlawful and set aside agency action not supported by substantial evidence.56 This standard applies both to the specific reclassification and to the attempt to promulgate a new rule. The Supreme Court's words in another case are perfectly appropriate here: There are no findings and no analysis here to justify the choice made, no indication of the basis on which [the agency] exercised its expert discretion. We are not prepared to and the Administrative Procedure Act will not permit us to accept such . . . practice. . . . Expert discretion is the lifeblood of the administrative process, but unless we make the requirements for administrative action strict and demanding, expertise . . . can become a monster which rules with no practical limits on its discretion.57 The record known to appellant is entirely silent as to the old rule's defects, the new ruleadvantages [sic], or any reasons whatsoever. BXA fails the substantial evidence test. C. BXA's new rule would undermine the existing rule and is vague. BXA's new rule is substantially different from the existing rule because it narrows the authentication exemption to exclude software that was previously exempt. The problem is more serious, however. BXA's new rule does not merely affect some software; it eviscerates the published rule. Appellant claimed above that the new rule's new concept, "modifiability," changes the rule's core meaning. He further argues here that without significant additional explanation, the new rule is vague to the core and thus offends due process in every application. Although usually framed in terms of fair notice to those subject to the law, "the more important aspect of [vagueness] 'is . . . the requirement that a legislature establish minimal guidelines to govern law enforcement.'"58 The new rule's central premise - "modifiability" - is so devoid of objective meaning that it infects every application with vagueness. BXA clearly recognizes the problem with an unvarnished modifiability standard, saying instead that the item must be easy to modify. But BXA has not defined "easily." For whom is it "easy"? Terms like "easily" or "with minimal programming effort" are meaningless without specifying some baseline. Without some objective standard here, "easily" is wholly discretionary and will foster arbitrary and capricious decisionmaking. Appellant seriously doubts that BXA can even administer, much less articulate, an "easy to modify" standard. Every classification request involving software would require some evidentiary record as to how easy it is to modify the software. Here, BXA on its own initiative reclassified the Software. BXA might have explained how the Software could be easily modified, thus fleshing out the rule in a specific case. But BXA did not. It did not even present any factual basis for its conclusion. If BXA could not provide elucidation here, there is no reason to think that it could in every case involving authentication software that uses encryption. Exporters have difficulty even with the simpler term "specially designed."59 That term has traditionally meant "used solely for."60 The suggestion that "specially designed" can be read to mean "capable of use" was met by negative comment. "Capable of use" is subject to the same objections as "can be easily modified," which mainly arise in connection with parts or components that can be used different ways. To control a general-purpose machine part because it could be used in controlled machines creates enormous vagueness problems.61 Encryption is clearly not specially designed for encryption; it is used for authentication as well. If encryption functionality is thought of as a machine part, we have a situation in which an item not subject to EI controls, authentication, normally uses a "part" that is subject to EI controls. The published rule clearly states that authentication software may use such a "part" so long as the program itself does not encrypt messages. BXA's new rule using "can be easily modified" changes that rule at its core because the encryption "part" can usually be removed from software and used differently. "Specially designed," at least, focuses on the item as it is. "Can be easily modified" sweeps far more broadly. Now we are no longer even looking at discrete controlled items into which parts or components can be inserted; we are looking at how the item could be modified. A particular problem here is software in source code form. All software can be modified - even software without encryption, like a word processing application, can have encryption added to it - and it is generally easier to modify software in source code form. BXA's new rule at the very least would categorize authentication software, especially in source code form, as encryption software.62 The problem is especially acute for DNS authentication software, which must contain encryption. While centered in the United States, DNS development is supported by developers worldwide who test, debug, and deploy DNS software on the Internet. DNS software development has for at least 12 years occurred through open publication in source code form, partly because it is more secure in that form. DNS source code can be read to ensure that it does not contain additional or modified code that could weaken or attack a system. Such malicious code would be much more difficult to detect in an object code distribution. This security is critical to the many high-security Internet sites that evaluate, test and use DNS software. The dangers of vagueness are especially serious for BXA's administration of EAR. Exporters are encouraged to classify items themselves.63 Under EAR, however, civil liability is strict liability: the exporter's intent is irrelevant.64 Indeed, one court has imposed a near-strict liability standard for criminal liability under EAR.65 Even BXA recognizes the need for "precise, objective criteria": "Broader, more subjective criteria would leave exporters . . . more dependent upon interpretations and rulings by BXA officials."66 For the authentication exemption to be reasonably relied upon, the definition must be public and clear. If the standard used for appellant is intended for future use but not publicly promulgated, exporters will not be able to self-classify.67 D. Agency discretion to promulgate rules in adjudication does not permit agencies to repeal existing rules without explanation. BXA does not write on a blank slate; an existing, unrepealed, published rule covers this very subject in a clear way. The APA establishes a scheme of "reasoned decisionmaking," and "[i]t is hard to imagine a more violent breach of that requirement than applying a rule . . . which is in fact different from the rule . . . formally announced."68 That is precisely the situation here. An agency must "explain its departure from prior norms," and "[w]hatever the ground . . . it must be clearly set forth so that the reviewing court may understand the basis of the agency's action and so may judge the consistency of that action with the agency's mandate."69 Agencies may, of course, promulgate legislative rules via adjudication. But rulemaking via adjudication requires at least an adequate explanation of why the rule is justified, and how it was applied. An "agency's failure to state its reasoning or to adopt an intelligible decisional standard [can be] so glaring that [a court] can declare with confidence that the agency action was arbitrary and capricious."70 Also, "an agency violates the APA when it fails to include in its adjudicatory decision a meaningful 'statement of findings and conclusions, and the reasons or basis therefor, on all the material issues of fact, law, or discretion presented on the record.'"71 On these criteria, BXA has failed. Moreover, rulemaking via adjudication must not be arbitrary in a given case. The agency "may not depart sub silentio, from its usual rules of decision to reach a different, unexplained result in a single case. . . . [T]here may not be a rule for Monday, another for Tuesday, a rule for general application, but denied outright in a specific case."72 As then-Judge Breyer explained: "Unless an agency either follows or consciously changes the rules developed in its precedent, those subject to the agency's authority cannot use its precedent as a guide for their conduct; nor will that precedent check arbitrary agency action."73 An agency "cannot . . . punish a member of the regulated class for reasonably interpreting [agency] rules. Otherwise the practice of administrative law would come to resemble 'Russian Roulette.' . . . . [I]f [the agency] wishes to use that interpretation to cut off a party's right, it must give full notice of its interpretation."74 Enforcement of a novel regulatory construction, without sufficient due process, is ipso facto arbitrary and capricious.75 BXA is bound by its regulations until it publishes the new rule. It has not done so. V. There is a strong public interest in DNS authentication and in open publication of DNS authentication software. Public policy interests support DNS authentication. As a general matter, the value of the Internet to the public at large depends on its reliability. People need to know that the information they send and receive is going to and coming from the right place. This issue is especially important for unencrypted information. For instance, an attacker could divert credit card numbers by manipulating DNS information. DNS diversion can also create Internet "traffic" problems that may lead to outages of significant portions of the Internet. A homely analogy might be to a malicious person removing or replacing street, road, and highway signs, thus redirecting traffic from one place to another. A. The U.S. government is funding DNS authentication software out of concern for critical infrastructure vulnerability. The U.S. government is now addressing the vulnerability of "critical infrastructures," including the Internet.76 Part of the government response to infrastructure vulnerability is to promote greater Internet security. An example is the DARPA Program on Information Survivability.77 DARPA's High-Confidence Networking group sponsored the work at Trusted Information Systems, Inc. ("TIS")78 from which the Software was derived. DARPA recognized that the Internet "infrastructure protocols [were] designed with an implicit trust in the integrity and authenticity of information received that is ill-suited for the present day Internet environment" so that "accidental failure or malicious attack by outsiders could result in widespread disruption of the Internet."79 The TIS research was intended to "prevent such disruptions by employing digital signature and other security techniques," which "are the cornerstone of protecting the Internet infrastructure from disruption."80 "[T]he inclusion of data integrity and data authentication security services in the Domain Name System protocol" will "provide protection from the propagation of inaccurate data and prevent machines from masquerading as other domain name system servers."81 B. To protect the Internet, DNS authentication must be freely publishable. Although the Software has been published, and as a result is now available worldwide, the overall goal of authenticating the DNS is far off. First, the Softwarae[sic] is but a prototype. Mr. Daniel's publication of the Software was merely an initial step intended to allow the global Internet community to test and improve it. No one knows how well it will really work. Also, there is little operational experience with a cryptographic authentication system this large. Today's Integrated DNSSEC requires much expertise to administer it correctly; for example, the owner of a DNS name must periodically manually re-sign its data and publish the new signature. The Software worked for a few researchers, but significant research and development will need to be done before the system becomes easy to administer. This cannot begin until it is discovered exactly what aspects chafe users and administrators of today's prototype. Second, for DNS authentication to protect the Internet as a whole, it must be ubiquitous within the DNS. DNS implementers outside the United States must use it as well. It is not sufficient for only the U.S. segment of the Internet to utilize the DNS Security Extensions. The transition to a secure DNS cannot interrupt existing use of the Internet, which means that end-users cannot today require every existing site to authenticate their DNS data. If they did, most of the Internet would be unreachable. Instead, the system must be secured piece by piece. For several years, users will be unable to demand that every access be authenticated. Eventually, enough of the DNS will be authenticated that the stragglers can be pushed into converting under a threat of becoming inaccessible; at that point end-user software can insist on authentication. If foreign sites cannot authenticate, that point will never be reached, leaving permanent loopholes that can be exploited to forge DNS data. Third, while appellant does not expect that DNS authentication software will itself be commercialized, its spread beyond testing and evaluation into the actual infrastructure will require its incorporation into commercial products. The President's Commission on Critical Infrastructure Protection ("PCCIP") emphasized that "[i]t is essential to have strong involvement from infrastructure owners and operators to ensure the development and acquisition of useful and usable products."82 Actual use of the DNS Security Extensions will depend on their being part of the default software bundle for machines that function as DNS servers and DNS clients - and that includes every machine on the Internet. Export controls on authentication will at least retard incorporation of authentication into commercial products. A PCCIP-sponsored study on information assurance ("IA") found that commercial technology firms are under-investing in important areas of IA R&D. The PCCIP reported that "[e]xport control policy is perceived to be the biggest barrier to further commercial IA investment, thereby reducing the capability to protect our critical infrastructures."83 Fourth, let us for a moment ignore the legal issues and focus merely on the practical. If DNS authentication software cannot be published freely, it leaves the Internet community with these choices, none of which benefits the United States: * Dropping the whole project and leaving the Internet inherently insecure. * Discarding the domestic, DARPA-sponsored DNS Security work, and paying foreigners to do the work again. This would not only lose U.S. leadership and engage more foreign programmers in cryptographic techniques, it would also create an incentive to move general DNS development overseas, because existing U.S. developers could not legally publish DNS software releases. It would also create an incentive for U.S. firms to move their release engineering overseas so that they could incorporate this technology into their ordinary software releases. If, instead, BXA applies its written regulations, the United States gets these benefits: * Gets a more secure Internet; * Keeps DNS development in the United States; * Keeps DNS Security development in the United States, funded and managed by the U.S. Government; * Avoids creating an incentive for U.S. operating system and Internet manufacturers to set up overseas release engineering that could make it easier for them to incorporate strong encryption for confidentiality; and * Encourages citizens to see government policy as reasonable. VII. BXA's actions of reclassifying the Software and of applying a new, spurious rule are subject to judicial review. There is a strong presumption in favor of judicial review of agency action, especially when a person is under threat of criminal liability. "[W]here a determination made in an administrative proceeding is to play a critical role in the subsequent imposition of a criminal sanction, there must be some meaningful review of the administrative proceeding."84 Appellant was warned that continuing to publish the Software would subject him to EAR liability. A. IEEPA does not statutorily preclude judicial review. While there is little judicial review of BXA action under the EAA, BXA does not now enjoy such immunity. EAA has lapsed and the only statutory authority for the regulations here, IEEPA, does not preclude judicial review.85 B. BXA's decision to reclassify the Software is not action committed to agency discretion by law. Agency action can be unreviewable because it is so "committed to agency discretion by law" that "in a given case there is no law to apply."86 BXA's actions here do not fall within this rare category87 because there are obvious sources of law: BXA's own published regulations,88 and basic notions of procedural due process in the APA and the Fifth Amendment. Conversely, the issues raised by appellant do not involve BXA's substantive expertise; they merely involve issues of legality. For the same reason, BXA's actions also do not present a political question doctrine; questions of regulatory construction are traditionally resolved by courts.89 C. BXA's rule is entitled to little if any judicial deference. BXA may argue that it is entitled to substantial deference because it is interpreting its own regulation.90 As argued earlier, the rule is so different from the published rule that it is a legislative rule. Even if it were not, however, such deference is not applied if the agency's interpretation is "plainly erroneous or inconsistent with the regulation."91 An agency interpretation is "entitled to considerably less deference" when the agency has not construed its regulations consistently and has not explained a change in position.92 Appellant has already shown that BXA's new rule is substantially inconsistent with the regulation which, in pertinent part, has remained unchanged since 1992. Courts are properly suspect of sharp departures from past practice that are as unexplained as BXA's here. Agency conduct, no less than express statements, can effect a construction of regulations.93 BXA's inconsistency in this particular matter - appellant's Software - further militates against deference. Here, BXA initially found that the Software was authentication software and then reversed itself.94 The reversal was not explained except by resort to a new, substantially different rule, and was apparently sparked by litigation considerations. D. Ultra vires or unconstitutional agency action is judicially reviewable. Even if BXA's action were prima facie unreviewable under the APA, appellant would still be entitled to judicial review. First, judicial review is generally available for claims that an agency exceeds its authority.95 Here, for example, BXA exceeded its self-defined regulatory jurisdiction by seeking to control software not "subject to the EAR." Appellant also has constitutional claims such as unlawful taking of property and deprivation of procedural due process. There is a virtually unrebuttable presumption favoring judicial review of such constitutional claims.96 Finally, one district court accorded First Amendment protection to software in source code form and held the EI regulatory scheme to be unconstitutional because the government has too much discretion.97 The arbitrariness of BXA's actions here will surely weigh in favor of judicial review. VIII. The Undersecretary may exempt the Software from EI controls even if he determines that it could properly have been classified as ECCN 5D002. At the end of the informal hearing, the hearing officer asked whether the Undersecretary could find that the reclassification was correct under BXA's new rule, but nevertheless exempt the Software from EI controls. Without conceding the validity of that hypothetical decision, appellant believes that the Undersecretary has an option here. First, as earlier argued, there is a strong presumption against retroactivity: "the legal effect of conduct should ordinarily be assessed under the law that existed when the conduct took place."98 Appellant had been publishing the Software legally, and he stopped only because BXA applied a new rule to his conduct. The situation is like that in Bowen v. Georgetown Univ. Hospital,99 where the regulation at issue impermissibly invoked a new substantive standard as a basis for recouping sums previously paid to hospitals. Here, a new substantive standard is the basis for reclassifying software already published and thus not subject to the EAR. Appellant should not be subject to a new rule for an item submitted and classified under the old rule, especially not before a new rule has been validly promulgated. Second, appellant relied on an express classification by BXA that the Software was authentication software. In reliance on that official action, appellant published the Software, rendering it not subject to the EAR. Courts are less likely to impose new liability "for past actions . . . taken in good-faith reliance on [agency] pronouncements."100 Third, appellant's situation is unusual in that he made the Software publicly available, so that it was not subject to the EAR and remains available on the Internet from foreign sources. Most exporters, appellant believes, prefer to keep their software proprietary. They are unlikely to take the critical step of making their software publicly available, so their software would remain "subject to the EAR." In short, appellant's situation simultaneously invokes three factors: retroactivity; reliance; futility. While no single factor might be dispositive, their unique combination here - plus the procedural irregularity of an apparently litigation-motivated reclassification - strongly favors the Undersecretary's exercising his discretion to not impose EI controls on the Software. CONCLUSION BXA acted unlawfully in a variety of ways. It exceeded its regulatory jurisdiction, failed to observe proper procedures, attempted to promulgate a vague and arbitrary legislative rule, and in so doing violated appellant's constitutionally and statutorily protected rights. For these reasons, appellant respectfully submits that the Undersecretary should reverse BXA's reclassification of the Software and declare the Software exempt from EI controls. If the Undersecretary is sympathetic to BXA's new rule, he should direct BXA to proceed in a fashion that is both procedurally legal and substantively responsive to the public interest. Respectfully submitted ___________________ LEE TIEN Counsel for appellant Mr. Hugh Daniel DATED: February 23, 1999 (Footnotes:) 1. Appellant contended that the Software was exempt under three rules. Appellant will focus on the "data authentication" exemption, on which BXA's original classification apparently relied. 2. Motor Vehicles Ass'n v. State Farm Mut. Auto. Ins. Co., 463 U.S. 29, 42 (1983). 3. 5 U.S.C. 706(2)(A). 4. Under the APA, the Software's classification and reclassification were adjudications . The original classification yielded an order classifying the Software as EAR99. BXA's reclassification was an order setting forth, in the letter, an unpublished, invalid legislative rule. 5. 15 C.F.R. 734.3(b)(3)(i) (1998). 6. 5D002 is the classification for encryption software subject to EI controls. 7. 15 C.F.R. 734.2(a)(1) (1998). 8. 15 C.F.R. 734.3(b)(3), 734.7(b) (1998). 9. There is no record dispute as to appellant's having made the Software publicly available. 10. BXA may argue that items "not subject to the EAR" can be reclassified as "subject to the EAR." Without jurisdiction, however, BXA cannot do so, and by EAR's plain terms "items and activities that are not subject to the EAR are outside the regulatory jurisdiction of the EAR." 15 C.F.R. 734.2(a)(1) (1998); 15 C.F.R. 734.1(a) (1998) ("If your item or activity is not subject to the EAR, then you do not have any obligations under the EAR."). It would be different if EAR stated that "items and activities not subject to the EAR may be made subject to the EAR" or that "'not subject to the EAR' means that BXA disclaims present jurisdiction over such items and activities, but reserves the power to assert jurisdiction over them." Appellant knows of no such language. 11. Bowen v. Georgetown Univ. Hosp., 488 U.S. 204, 208 (1988). 12. Ibid. 13. Landgraf v. USI Film Products, 511 U.S. 244, 270 (1994). 14. Bowen, 488 U.S. at 219 (Scalia, J., concurring) (emphasis in original). 15. Landgraf, 511 U.S. at 270. 16. 15 C.F.R. Part 774, Category 5.II., 5A002 (1998); see also id. at 5D002. 17. 57 Fed. Reg. 15227, 15228, 15233 (April 27, 1992); 22 C.F.R. 121.1 (1993). 18. 61 Fed. Reg. 68572, 68575 (Dec. 30, 1996) ("Software and technology that was controlled by the Department of Commerce prior to December 30, 1996 are not affected by this rule and will continue to be eligible for the publicly available treatment."). 19. 22 C.F.R. 121.1 Category XIII(b)(1)(vi) (1993). Prior to requesting classification from BXA, appellant had submitted a commodity jurisdiction request to the State Department under ITAR. Appellant's counsel spoke with a National Security Agency representative on Dec. 10, 1996 regarding the Software; she informally stated that the request appeared to be within this category. Classification Request Letter, n. 1 (April 27, 1997). 20. 15 C.F.R. Part 774, 5A002 Note g. (1998). EAR further provides that "5D002 does not control . . . '[s]oftware' providing any of the functions of equipment excluded from control under the Note to 5A002." Id., 5D002 Note. 21. Appellant also contends that IEEPA does not permit BXA to enforce EI controls on the Software. Appellant's Administrative Appeal Letter, at 6-7 (July 30, 1998). 22. 61 Fed. Reg. 68572, 68573 (Dec. 30, 1996). 23. 15 C.F.R. Part 774 Category 5.II., 5D002. (1998). 24. 15 C.F.R. Part 772 (1998) (definition of "designed or modified"). 25. Id. (definition of "commodity"). 26. The Software uses the Data Encryption Standard ("DES") for this purpose. 27. For example, the DNS data associated with "www.bxa.doc.gov" would be signed by BXA. Only BXA could change the relevant DNS data because only BXA can sign it; a forger's daata would be rejected because it was not signed by BXA. DNS users would know that BXA's signatures are valid because BXA's key is signed by DOC's key ("doc"), which is signed by the "gov" key, which in turn is signed by the "root key," administered by the Internet Corporation for Assigned Names and Numbers. By knowing a single well-publicized "root key," any Internet user's software would be able to check the authenticity of every datum it retrieved from the DNS. 28. BXA may also be concerned that a policy that says "RSAREF alone is unexportable, RSAREF in a confidentiality application is unexportable, but RSAREF in an authentication application is exportable" will be viewed as inconsistent. This concern was evident in Mr. Lewis's declaration in Karn. The legally sound answer would have been that the regulations turn on an application's function as designed. 29. Libraries faster and better than RSAREF, written outside the United States, are distributed worldwide. Foreign entities wishing to write encryption software are unlikely to use RSAREF's old, slow code, which also limits any resulting product to non-commercial uses only. A reason that RSAREF is used by the Software is that it permits domestic use of patented technology; the patent is not valid outside the United States. Also, the government-sponsored work on which the Software is based was designed to use RSAREF. See Gudmundsson, O., R. Mundy, and S. Murphy, Technical Description of the TIS Implementation of the Domain Name System Security Extensions at 3 (May 17, 1996) (submitted with classification request) ("Gudmundsson"). BXA may also be concerned that the DES in RSAREF can be used for confidentiality. DES is not public-key cryptography, but it is necessary to protect the stored keys used for authentication. 30. Lewis Decl., para. 4. 31. Id., para. 5. 32. One might ask whether BXA's reclassification was based on new facts, given BXA's hinting that its EAR99 classification was "in error." Id., para. 6. BXA's saying that the EAR99 classification was "based on what BXA understood the application of [the Software] to be," id., para. 4, implies that BXA learned something new on reclassification. But there were no different facts. BXA stated only that on reclassification it "determined that, while the RSAREF is used in Integrated DNSSEC to authenticate users or messages, the software also included the source code for RSAREF." Id., para. 5. That the Software includes RSAREF was fully disclosed to BXA in appellant's classification request. Id., para. 4. BXA also states that its EAR99 classification was based on appellant's classification request having "described" the Software, id., para. 4, while its reclassification was based on actual review of the software. Id., para. 5 fn. 2. The obvious implication is that appellant did not provide the Software for BXA's initial classification review. Here, BXA was not forthright with the court. Appellant's classification request did not merely describe the Software - it included the source code for the entire program on disk. Any implication that appellant failed to provide all relevant facts to BXA would be unjustified. 33. Four factors are relevant: whether the rule is necessary in order for the agency to act; whether the rule was published; whether the agency explicitly invoked its general legislative power; whether the rule effectively amends a prior legislative rule. "If the answer to any of these questions is affirmative, we have a legislative, not an interpretive rule." American Mining Congress v. Mine Safety Health Administration, 995 F.2d 1106, 1112 (D.C. Cir. 1993). BXA at the very least published the authentication exemption in the Federal Register and exercised its general legislative power in so doing. 15 C.F.R. 730.1, 730.2 (1998). 34. United States v. Nixon, 418 U.S. 683, 695-696 (1974); Accardi v. Shaughnessy, 347 U.S. 260, 268 (1954). 35. Nader v. Bork, 366 F.Supp. 104, 108-109 (D.D.C. 1973) (firing of special prosecutor contrary to rules not retrospectively validated by revocation of rules three days later). 36. Bd. of Regents v. Roth, 408 U.S. 564, 577 (1972). 37. A person may have a Fifth Amendment property interest in information. Ruckelshaus v. Monsanto Co., 467 U.S. 986, 1003-1004 (1984). 38. Wolff v. McDonnell, 418 U.S. 539, 558 (1974) ("[A] person's liberty interest is [] protected, even when the liberty itself is a statutory creation . . . . The touchstone of due process is protection of the individual against arbitrary action of government.") (citation omitted). Export controls must be construed to avoid interfering with the exchange of scientific and technological information and ideas. United States v. Edler Industries, Inc., 579 F.2d 516, 519 (9th Cir. 1978). Any such scheme must not violate First Amendment due process, and one court has found EAR's application to cryptography unconstitutional on precisely these grounds. Bernstein v. U.S. Dep't of State, 974 F.Supp. 1288, 1308 (N.D.Cal. 1997). Although the court's injunction was stayed pending appeal, the holding casts significant doubt on both the legality and power of BXA to enforce restrictions on appellant and his intended continued publication of the Software. The main consideration deemed important in Bernstein - lack of definite standards to control agency discretion - is exactly the problem with BXA's actions here. Indeed, BXA's action here is more problematic. In Bernstein, at least, there was no doubt that the software was subject to EI controls. Here BXA initially found that the Software was not subject to EI controls at all, indicating an even greater degree of arbitrariness. 39. "[A]t a minimum [due process] require[s] that deprivation of . . . liberty or property by adjudication be preceded by notice and opportunity for hearing appropriate to the nature of the case." Mullane v. Central Hanover Bank & Trust Co., 339 U.S. 306, 313-314 (1950). 40. General Electric Co. v. U.S. EPA, 53 F.3d 1324, 1329 (D.C. Cir. 1995) (question is "whether the regulated party received . . . notice . . . in the most obvious way of all: by reading the regulations."). 41. Martin v. OSHRC, 499 U.S. 144, 158 (1991). 42. 5 U.S.C. 552(a)(1)(D); id., at (a)(1)(E) ("each amendment, revision, or repeal"). 43. 5 U.S.C. 552(a)(1). 44. Appellant received notice, but it was not timely because it occurred after the reclassification. 45. 5 U.S.C. 558(c). 46. Ibid. 47. 5 U.S.C. 556(d); Director, Ofc. of Workers' Comp. Programs v. Greenwich Collieries, 512 U.S. 267,275- 276 (1994) (burden of proof means persuading trier of fact on "ultimate issue"). 48. Cf. Local 2855, AFGE (AFL-CIO) v. United States, 602 F.2d 574, 580 (3d Cir. 1980) (agency action reviewable if "occasioned by impermissible influences"); Curran v. Laird, 420 F.2d 122, 131 (D.C. Cir. 1969) ("use of procedurally unfair and unauthorized techniques , inflicting injury on private citizens"). 49. Martin, 499 U.S. at 156. 50. National Wildlife Federation v. Browner, 127 F.3d 1126, 1129 (D.C. Cir. 1997) (citing FLRA v. U.S. Dep't of Treasury, 884 F.2d 1446, 1455 (D.C. Cir. 1989)). 51. National Family Planning and Reproductive Health Ass'n, Inc. v. Sullivan, 979 F.2d 227, 235 (D.C. Cir. 1992) (citation omitted). 52. There is no evidence in the record as to the validity of this claim. 53. Most personal computers can encrypt for confidentiality if loaded with encryption software, which is not difficult to do, but that does not make them encryption items. 54. 15 C.F.R. Part 774 (1998) (definition of "encryption item"). 55. Thus, BXA's new rule is a legislative rule under American Mining. See n. 33. 56. 5 U.S.C. 706(A)(2)(E), (A)(2)(F) ("unwarranted by the facts"). 57. Motor Vehicles, 463 U.S. at 48. 58. Kolender v. Lawson, 461 U.S. 352, 358 (1983) (citation omitted). In the "logically related" area of overbreadth, id. at 358-359 n. 8, a law may be unconstitutional when "there is no core of easily identifiable . . . conduct that it prohibits." Sec'y of State of Md. v. Joseph H. Munson Co., 467 U.S. 947, 965-66 (1984). Because the rule is an exemption, the converse problem exists: there is no core of easily identifiable conduct that the rule permits. 59. Request for Comments on the Definition of "Specially Designed," 62 Fed.Reg. 56138 (Oct. 29, 1997). 60. "Used solely for" has long meant that "an item/software/technology . . . could not be used in or for another item." Comment of Mr. Robert J. Anstead (Nov. 28, 1997). Mr. Anstead was head of the Office of Strategic Trade and Foreign Policy Controls in 1994. 61. Comment of Semiconductor Industry Association, 1 (Dec. 29, 1997) ("term 'specially designed' is of particular importance for parts, components, and subassemblies . . . . If the term has no clear bounds or cannot be readily understood, the scope of the regulations will become confusing, overreaching, and unfair."). 62. Also, the published rule does not distinguish source and object code, which is consistent with the guiding principle that items are classified based on what they do - but not with a rule that classifies items based on what they can be modified to do. 63. 15 C.F.R. 732.3(b) (1998) ("You should classify your items . . . and you may do so without the assistance of BXA."). 64. Iran Air v. Kugelman, 996 F.2d 1253, 1258-1259 (D.C. Cir. 1993). 65. United States v. Shetterly, 971 F.2d 67, 73 (7th Cir. 1992) (criminal liability may attach without knowledge that license is required so long as export itself is "knowing"). 66. 15 C.F.R. 730.8(b) (1998). 67. If BXA does not intend to use the "can be easily modified" standard in future cases, then its application to appellant is arbitrary and capricious. 68. Allentown Mack Sales and Service, Inc. v. NLRB, 118 S.Ct. 818, 827 (1998). 69. Atchison, T. & S. F. R. Co. v. Wichita Bd. of Trade, 412 U.S. 800, 808 (1973) (plurality). 70. Checkosky v. SEC, 23 F.3d 452, 463 (D.C. Cir. 1994) (Silberman, J.). 71. Checkosky v. SEC, 139 F.3d 221, 226 (D.C. Cir. 1998) (citing 5 U.S.C. 557(c)(3)(A)). 72. Shaw's Supermarkets, Inc., v. NLRB, 884 F.2d 34, 37 (1st Cir. 1989) (footnotes and citations omitted). 73. Id. at 41; see Atchison, 412 U.S. at 807-808. 74. Satellite Broadcasting Co. v. FCC, 824 F.2d 1, 3-4 (D.C. Cir. 1987). 75. Ibid. See also Martin, 499 U.S. at 158. 76. Last week, the Secretary of Defense publicly stated that there is a strong public interest in securing the Internet. He discussed with Microsoft head William Gates "how the government can work with private-sector companies to secure the 'critical information infrastructure' that manage power grids, telecommunications, and highway, aviation, and other transportation systems." Defense Secretary Defends Microsoft, Computer Reseller News (02/19/99, 10:54 a.m. ET). 77. Report of the President's Commission on Critical Infrastructure Protection, Research and Development Recommendations for Protecting and Assuring Critical National Infrastructures 6 (1997) ("PCCIP R&D Recommendations"), citing Lunt, T., DARPA Program on Information Survivability, presentation (Aug. 1997). 78. Gudmundsson, at 2, citing Contract Number DABT 63-94-C001 ("Internet Infrastructure Protection") (1994). 79. DARPA ITO Sponsored Research, 1997 Project Summary, Internet Infrastructure Protection, Trusted Information Systems, Inc. . 80. Ibid. 81. Ibid. 82. PCCIP R&D Recommendations iv. 83. Id., at 8, citing Mayfield, W., and R. Ross, Evolving a National Information Assurance Research Agenda: Issues and Opinions from Commercial Information Technology Providers, report prepared for the President's Commission on Critical Infrastructure Protection by Institute for Defense Analyses, Alexandria, Va. (July 1997). 84. United States v. Mendoza-Lopez, 481 U.S. 828, 837-838 (1987) (emphasis in original). 85. Milena Ship Mgmt. Co. v. Newcomb, 804 F.Supp. 846, 850 (E.D.LA. 1992), aff'd, 995 F.2d 620 (5th Cir. 1993), cert denied, 510 U.S. 1071 (1994); Nuclear Pacific, Inc. v. U.S. Dep't of Commerce, No. C 84 - 49R (W.D. Wash. June 8, 1984). 86. Citizens to Preserve Overton Park, Inc. v. Volpe, 401 U.S. 402, 410 (1971). 87. BXA's actions fall into none of the four types of "rare circumstances" regarded as "committed to agency discretion": decisions not to take enforcement action; refusal to grant reconsideration of an action because of material error; decisions to terminate an employee for national security reasons; and decisions about allocating funds from a lump-sum appropriation. Lincoln v. Vigil, 508 U.S. 182, 191-192 (1993). 88. Massachusetts Public Interest Research Group, Inc. v. NRC, 852 F.2d 9, 16 (1st Cir. 1988) (agency regulations can "provide a sufficient standard for judicial review"); Center for Auto Safety v. Dole, 846 F2d 1532, 1534 (D.C. Cir. 1988). 89. Stehney v. Perry, 101 F.3d 925, 932 (3d Cir. 1996); Japan Whaling Ass'n v. American Cetacean Soc'y, 478 U.S. 221, 230 (1986). 90. Strictly speaking, the authentication exemption is not even BXA's own regulation, because it mirrors the ITAR provision transferring authentication items to DOC. 91. Stinson v. United States, 508 U.S. 36, 45 (1993) (quoting Bowles v. Seminole Rock & Sand Co., 325 U.S. 410, 414 (1945). 92. Thomas Jefferson Univ. v. Shalala, 512 U.S. 504, 515 (1994) (citation and quotation marks omitted). 93. See Motor Vehicles, 463 U.S. at 41-42 ("[a] 'settled course of behavior embodies the agency's informed judgment that, by pursuing that course, it will carry out the policies [of applicable statutes and regulations]'") (quoting Atchison, 412 U.S. at 807-808). 94. Rollins Envtl. Servs., Inc. v. EPA, 937 F.2d 649, 653 (D.C. Cir. 1991) (when "agency itself is uncertain of the meaning of its regulation" and "agency personnel give conflicting advice to private parties about how to comply with it," it is "arbitrary to find the regulation 'clear'"). 95. 5 U.S.C. 706(2)(A); id., (C) ("in excess of statutory jurisdiction, authority, or limitations"); e.g., Service v. Dulles, 354 U.S. 363 (1957); McAlpine v. United States, 112 F.3d 1429, 1433-34 (10th Cir.), cert. denied, 118 S.Ct. 447 (1997); NLRB v. Kemmerer Village, Inc., 907 F.2d 661, 663 (7th Cir. 1990); Guadamuz v. Bowen, 859 F.2d 762, 767 (9th Cir. 1988); cf. Wright v. Roanoke Redevelopment & Hous. Auth., 479 U.S. 418, 431 (1987). 96. Webster v. Doe, 486 U.S. 592, 603 (1988). 97. Bernstein, 974 F.Supp. at 1308. 98. Landgraf, 511 U.S. at 265 (citation omitted). 99. 488 U.S. 204 (1988). 100. NLRB v. Bell Aerospace Co., 416 U.S. 267, 295 (1974).