The Honorable William Reinsch
Under Secretary for Export Administration
Bureau of Export Administration
U.S. Department of Commerce
Room H-3886C
14th Street and Pennsylvania Avenue, N.W.
Washington, D.C.  20230

				Appl. Ref. No.:  Z066051/G006298

Dear Sir:

	This administrative appeal letter concerns the reclassification of
a computer program for authentication written to improve the security of
the Internet's Domain Name Service system, called Integrated DNSSEC ("the
Software").  Last year, the Bureau of Export Administration ("BXA")
officially classified the Software as authentication software (EAR99) not
subject to encryption item ("EI") controls.. Recently, however, a BXA
official stated that the Software had been reclassified as ECCN 5D002
subject to encryption item ("EI") controls.

	Because items subject to EI controls are not eligible for public
availability treatment, this action directly and adversely affected my
client by forcing him to stop freely publishing the Software over the
Internet.  He was thus deprived of a legitimate claim of entitlement to
publish the Software.  See, e.g., 15 C.F.R. 734.3(b)(3)(i).

	This letter appeals that reclassification and requests an informal
hearing pursuant to 15 C.F.R. Part 756.  It also requests information
necessary to the proper presentation of this appeal and seeks permission to
supplement this appeal letter following receipt of such information.  15
C.F.R. 756.2(c) (authorizing Under Secretary to "adopt any other
procedures deemed necessary and reasonable for considering an appeal").

Factual and procedural background

	I 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").  My cover letter made
clear that the Software contained RSAREF, but used it only for
authentication.

	BXA subsequently informed me that the Software was classified
EAR99.  In reliance on this classification, the Software was published over
the Internet to all persons, domestic and foreign.  It is my understanding
that EAR99 technology is governed by EAR's public availability provisions
because it is not controlled for EI reasons, and conversely, that only
technology controlled for EI reasons is ineligible for public availability
treatment.

	On June 19, 1998, I received by fax a letter from Mr. James Lewis
("Lewis letter"), stating that BXA had withdrawn its prior EAR99
classification for the Software and reclassified it as ECCN 5D002 "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 Lewis letter warned that Internet
publication of the Software "without any precautions to prevent its
unauthorized transfer outside the United States" would be an unlawful
export.  I immediately advised my client that he should cease making the
Software publicly available.

Request for additional facts

	I need further facts to appeal effectively, and request permission
to supplement this appeal letter after I receive such additional facts.
These facts concern:  (i) the actions taken by BXA on the initial
classification request, which resulted in the EAR99 classification; (ii)
the actions taken by BXA on the reclassification to ECCN 5D002; and (iii)
the train of events that led to BXA's revisiting this classification in the
first place.

	The relevance of the facts as to (i) and (ii) is unexceptional.
The original classification request explained what the Software contained,
and the Software including RSAREF was provided on a floppy disk in source
code form for BXA's review.  It is unclear to me at this time why the
reclassification resulted in a different outcome.  Did BXA initially not
review the provided information?  Did BXA receive information from another
source in the reclassification, and if so, what information?  Was it
material?  Or did a different person review the same information but decide
differently?

	As to (iii), I believe that the reclassification of the Software
may have been triggered by ongoing litigation, namely Karn v. U.S.
Department of State, et al., Civ. A. No. 95-1812-LFO (D.D.C.).  The
plaintiff, Mr. Philip R. Karn, contended that the government acted
inconsistently in classifying the Software as EAR99 and the plaintiff's
diskette containing cryptographic software as ECCN 5D002.  Mr. Lewis then
submitted a declaration in Karn that indicates that the reclassification of
the Software probably occurred in response to Mr. Karn's contention.
Declaration of Mr. James Lewis, para. 4 (June 19, 1998) ("Lewis Decl.").

	In his declaration in Karn, Mr. Lewis briefly discussed the
reclassification of the Software.  He stated that the April 1997
classification request specifically noted that the Software uses RSAREF.
Lewis Decl., para. 3.  Mr. Lewis, however, did not mention that the Software
had been submitted on disk for BXA's review.  Thus, when Mr. Lewis stated
that BXA on reclassification "determined that . . . [the Software] also
included the source code for RSAREF," Lewis Decl., para. 5, he stated merely
what BXA already knew at the time of the initial EAR99 classification.  Mr.
Lewis did not, so far as I can discern, identify any difference between
what BXA knew about the Software then and now.

	Accordingly, I ask to be provided with facts about how the initial
classification was processed and the circumstances surrounding BXA's
reclassification of the Software, especially the relationship between the
reclassification and the Karn litigation.

	Lacking all the facts, I cannot at this time state a legal argument
based on these circumstances, but I believe that the existence of any such
relationship is relevant to the propriety of BXA's reclassifying the
Software.  If in fact the litigation triggered the reclassification, BXA
arguably abused its discretion by directly and adversely affecting my
client simply to improve or maintain a position in litigation to which he
is not a party.  If the litigation did trigger the reclassification,
prejudgment may infect this administrative appeal because BXA is involved
in the Karn litigation and you yourself are a named defendant in Karn in
your official capacity.

Request for additional information about BXA's interpretations

	In order to appeal effectively, I also need to understand how BXA
distinguishes between authentication software and encryption software.  It
would be especially helpful to know whether BXA considers the previous
EAR99 classification to be incorrect, or whether BXA has only decided that
ECCN 5D002 is a better choice between two alternatives.

	Because at the time of the first classification BXA apparently knew
the same facts that it knew at the time of the reclassification, it would
seem that the only valid justification for changing the classification
could be that the legal criteria had changed.
Mr. Lewis's declaration quoted my cover letter as stating that "the
encryption capability of the software is limited to encryption of data
needed for authentication."  Lewis Decl., para. 4.  But his declaration did not
dispute this description for the Software as written.  Rather, he stated
that the Software "included the source code for RSAREF," which "with
minimal amount of programming effort," can be used to encrypt data "for
confidentiality purposes."  Lewis Decl., para. 5.  The Lewis letter, meanwhile,
stated that the Software was reclassified as ECCN 5D002 because it "can be
easily modified to do encryption."  Thus, Mr. Lewis appeared to accept that
the Software, as written, only encrypts as needed for authentication.

	So far as I can determine, the concept of "modifiability" is
neither expressly set forth nor defined in the EAR.  The definitions set
forth in 15 C.F.R. Part 774 define "designed or modified," but only for the
Missile Technology Control Regime.  Even this definition does not speak of
"modifiability."

	I therefore ask that I be informed of any relevant changes,
published or unpublished, in BXA's classification criteria between the time
of the original classification as EAR99 and the reclassification as ECCN
5D002.  In particular, I request clarification as to how BXA operationally
defines "can be easily modified" or "with minimal amount of programming
effort."

	Finally, I also request that I be provided with a copy of every
memorandum, brief, or other response to this appeal letter submitted to you
by BXA or any other interested government entity.  Doing so here would
improve the decisionmaking process, comport with basic procedural due
process, and facilitate later judicial review of this matter if necessary.
Because the issues presented in this case are essentially legal, it is
unlikely that such memoranda would contain confidential or sensitive
information.  Any such information could be redacted.

Legal arguments

	1.	The classification criterion enunciated by Mr. Lewis, i.e.,
software that "can be easily modified to do encryption," is not evident in
the black-letter regulations.  The regulatory text refers to whether
software is "designed or modified" to encrypt for confidentiality.  See,
e.g., 15 C.F.R. Part 774 Category 5.II. (5D002.a "controls 'software'
designed or modified to use 'cryptography' employing digital or analog
techniques to ensure 'information security'"); 61 Fed. Reg. 68572, 68573
(Dec. 30, 1996) ("This rule amends the Export Administration Regulations
(EAR) by imposing national security and foreign policy controls ('EI' for
Encryption Items) on certain information security systems and equipment,
cryptographic devices, software and components specifically designed or
modified therefor, and related technology ('encryption items')").  Mr.
Lewis's approach seems to change the definition stated in the regulations.

	a.	There is an enormous difference between that which is
designed or modified to encrypt for confidentiality, and that which can be
designed or modified to encrypt for confidentiality.  Most personal
computers can encrypt for confidentiality if loaded with cryptographic
software, which does not seem difficult, but personal computers are not
encryption items.

	Thus, as a general matter, the classification criteria enunciated
by Mr. Lewis, i.e., software that "can be easily modified to do
encryption," appears to encompass all software, of all types, that is
published in source code.  It is my understanding that any program that
creates files, documents, or output of any kind can be modified so as also
to encrypt such output.

	While the criterion stated by Mr. Lewis is not "can be modified"
but "can be easily modified," no explanation of "easily" is provided.
Exporters have difficulty even with the simpler term "specially designed."
Request for Comments on the Definition of "Specially Designed," 62 Fed.Reg.
56138 (Oct. 29, 1997).  "Specially designed," at least, focuses on the item
as it is.  "Can be easily modified" sweeps far more broadly.  For whom is
it "easy"?  Terms like "easily" or "with minimal programming effort" are
meaningless without specifying some baseline point of reference.  There
must be some objective standard here, like the patent-law rubric of a
person "reasonably skilled in the art."  Otherwise, "easily" is wholly
discretionary and will result in arbitrary and capricious decisionmaking.

	Further, I am concerned that BXA's operational definition may hinge
on whether a program is published in source code form.  Is BXA claiming
authority to regulate every program that is published in source code?  If
so, then there is a much bigger problem, because my clients publish many
kinds of software in source code.  If not, please provide me with a clearer
definition that citizens can use to determine the legality of their actions
when contemplating publication of items otherwise uncontrolled by your
regulations.

	b.	More narrowly, the "can be easily modified" criterion
conflicts directly with the explicit exemption for authentication items.
Authentication software often contains encryption; Mr. Lewis's letter and
declaration both appear to recognize that authentication software does
"encrypt files for authentication."  I believe that most, if not all,
programs in source code form that fit the authentication exemption also
"can be easily modified" to encrypt for confidentiality by a sufficiently
skilled person.  There is a very clear problem here if the boundaries of an
entire category of expressly exempt programs depends on the ambiguous
concept of "can be easily modified."

	Is BXA seriously suggesting that the entire category of
authentication programs has somehow been implicitly reclassified into the
larger category from which it was explicitly exempted?  The checkered
history of encryption export controls at the State Department included
similar examples, such as the availability of the public domain exemption
for "information" but software's being internally considered as "not
information."  I would be surprised to find BXA undermining the rule of law
by gerrymandering its categories in similar fashion, especially given the
scrutiny being given to the regulations by various federal courts.

	There are obvious dangers to procedural due process here.  BXA
export controls are already highly discretionary and an undefined standard
only exacerbates all the well-known dangers of vagueness.  Citizens will
lack notice of the legality of their actions; officials will not be guided
by law; courts will lack standards with which to decide whether official
action is legal.

	Regardless of BXA's statutory discretion, BXA has promulgated its
own regulations and is bound to follow them.  Given the exemption for
authentication software from EI controls, a reasonable reading of the
regulations is that when authentication software contains built-in
encryption, but the package as a whole only authenticates and is not
designed to provide encryption for confidentiality, then it is
authentication software, not encryption software.  Otherwise, supposedly
decontrolled authentication software will still be potentially controlled
because it contains encryption, even if the authentication software as
written cannot be used for confidentiality.

	I have advised my clients, for now, that the letter of the
regulations exempting authentication items from EI controls remains in
force.  I would like to advise them that authentication programs are
reviewed on the basis of what they do as published, rather than on what
they might do if someone rewrites them.  If a program is regulated for its
function, it seems either unsupportable or empty to regulate it for
functions that it lacks but which someone might add to it.

	2.	BXA lacks the legal authority to apply EI controls to
Integrated DNSSEC because jurisdiction over authentication software was
transferred to the Department of Commerce prior to Nov. 15, 1996.

	By its terms, the EI regulations, 61 Fed. Reg. 68572 (Dec. 30,
1996), state that 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."  15 C.F.R. Part 774,
Category 5.II., 5A002; see also id. at 5D002.  Jurisdiction over
"authentication software," however, was transferred to the Commerce Control
List prior to Nov. 15, 1996.  It is my understanding that the transfer of
jurisdiction over authentication software occurred via 1992 amendments to
the International Traffic in Arms Regulations ("ITAR").  See 57 Fed. Reg.
15227 (April 27, 1992).

	In short, EI controls, including the special restriction that
EI-controlled items cannot be made "publicly available," can only be
applied to items transferred under authority of the Nov. 1996 executive
order - and authentication software was transferred earlier.  It follows
that there cannot be EI controls on authentication software, that BXA lacks
the legal authority to override EAR's public availability provisions for
authentication software, and Integrated DNSSEC can be made publicly
available.

	3.	I further contend that EAR, inasmuch as it is presently
based on the International Economic Emergency Powers Act ("IEEPA"), does
not permit BXA to exercise regulatory authority over the Software.   IEEPA
contains a general exemption for "information" and "informational
materials."  50 U.S.C. 1702(b)(3).  This amendment, enacted on April 30,
1994, limits IEEPA authority and was enacted to permit Americans to
"shar[e] information and ideas with persons around the world."  H.Rep. No.
482, 103rd Cong., 2d Sess. 238, 1994 USCCAN 302, 483.  Congress amended
IEEPA specifically to address "restrictive" agency interpretations of "the
language in ways not originally intended."  Id., 1994 USCCAN 302, 483.
Indeed, the amendment expressly added CD ROMs, an important medium for
disseminating computer software.

	Although the "informational materials" exemption itself exempts
certain material "otherwise" controlled under the Export Administration Act
("EAA"), that internal exemption does not apply here.  When a statute
specifically refers to another statute, as IEEPA refers to the EAA, "[s]uch
adoption takes the statute as it exists at the time of the adoption and
does not include subsequent additions or modifications of the statute so
taken unless it does so by express intent."  Hassett v. Welch, 303 U.S.
303, 314 (1938) (quotation and citation omitted).

	In IEEPA, Congress did not express any intent to incorporate later
modifications to the EAA/EAR scheme.  The government has properly
interpreted this exemption in similar situations.  See, e.g., 31 C.F.R.
560.210(c), 560.315 (Iranian transactions controls of the Office of Foreign
Assets Control).  To read IEEPA otherwise would permit BXA to regulate
informational materials under EAR, nullifying the exemption.

	Thus, this reference to EAA at most calls into play the regulatory
scheme as of April 30, 1994.  At that time, authentication software was
already regulated by BXA, and eligible for EAR's general public
availability provision.  It follows that the Software remains eligible for
public availability treatment.

Conclusion

	The conflicting decisions as to the Software, as well as BXA's
seemingly ad hoc statement of the can-be-modified "with minimal effort"
criterion, do not seem to generalize to a clear rule.  Moreover, this
time-consuming process produces decisions that are either inconsistent with
the published regulations or eviscerate them by implication.  Even if
persons get permission from BXA, they run the same risk as if they had
never received a license or classification, since in either case BXA can
merely write a letter and make further publication presumptively illegal.
The arbitrariness of this process thus makes it more likely that those who
wish to publish software that is exempt from the EAR will simply publish
without submitting a commodity classification request.

	If BXA has a general rule distinguishing exempt authentication
programs from not-exempt "can easily be modified" encryption programs, it
should be published as a proposed EAR revision.  Public comment may enable
BXA to promulgate a rule that gives the public adequate notice for
rule-of-law and Administrative Procedure Act purposes as to when an
authentication program that could be modified to do encryption crosses the
line for export control purposes.

	For the reasons stated above, I request that the original EAR99
classification of Integrated DNSSEC be reinstated.
Sincerely yours,


Lee Tien