daveb@geac.UUCP (David Collier-Brown) (02/18/88)
This is a memo prepared by Digital's lawyers in response to John
Gilmore's note of last October. Please note that I am only passing this
along, without comment -- I know little if anything about the law, and
am not in the least interested in engaging in debate about this issue,
nor am I willing to pass such debate back to the lawyers piecemeal.
chris
--------Begin Forwarded Message
From: ehrgood@wnpv01.enet (TOM EHRGOOD, WNP, DTN 427-5698)
To: @cryptomemo.dis, ehrgood
Subject: Crypto Export Controls - Answer To Gilmore
_____________________________
| | | | | | | |
| d | i | g | i | t | a | l | I n t e r o f f i c e M e m o
|___|___|___|___|___|___|___|
TO: "TO" Distribution DATE: 16 February 1988
FROM: Tom Ehrgood
CC: "CC" Distribution DEPT: Corporate Law
TEL: (202) 383-5698
LOC: WNP
SUBJECT: Controls Over The Export Of Cryptographic Software
This memo answers points made in an October 27, 1987, memo by John
Gilmore, which we received on January 28th. Gilmore's memo, which I am
separately forwarding, argues that the posting of cryptographic software
to certain widely available bulletin boards places that software in the
"public domain," with the consequence that export licenses are not
required for the exports of that software. Gilmore's analysis has been
given wide distribution on various networks.
Gilmore is mistaken in his analysis and in his conclusion. Given the
high national security sensitivity of cryptography, generally, and DES
encryption, specifically, it is important to set the record straight.
The fundamental points that Gilmore gets wrong are:
o Exports of cryptographic software are governed by the State
Department's International Traffic in Arms Regulations ("ITAR"),
not by the Commerce Department's Export Administration
Regulations ("EAR"). Exports would be governed by Commerce's
EAR only if State waived jurisdiction.
o Although State Department regulations contain a "public domain"
exemption for technical data, cryptographic software does
not qualify as "technical data," and thus the "public domain"
exemption does not apply.
A legal analysis follows.
DISCUSSION
I. State Department Control Over Cryptographic Software
----------------------------------------------------
A. Cryptographic software is a "defense article"
---------------------------------------------
Section 38 of the Arms Export Control Act authorizes the President to
control the export and import of "defense articles" and "defense
services." This statutory authority -- which includes the authority to
to "designate those items which shall be considered as defense articles
and defense services" -- was delegated to the Department of
State, which in turn has implemented the statutory authority through
promulgation of the International Traffic in Arms Regulations ("ITAR"),
22 C.F.R. Subch. M.
The term "defense article" is defined in section 120.7 of ITAR to mean
"any item designated in section 121.1," which contains the United States
Munitions List.
Category XIII of the Munitions List provides in paragraph (b) as
follows:
Speech scramblers, privacy devices, CRYPTOGRAPHIC DEVICES AND
SOFTWARE (ENCODING AND DECODING), and components specifically
designed or modified therefore, ancillary equipment, and protective
apparatus specifically designed or modified for such devices,
components, and equipment. (Emphasis added.)
Since "cryptographic . . . software" is thus included on the United
States Munitions List, it is a "defense article" subject to the State
Department's ITAR controls over exports of such articles.
At certain low thresholds, it may not be clear whether software
containing certain encryption functionality in a technical sense
constitutes "cryptographic software" within the meaning of Category
XIII(b), above. Section 120.5 of ITAR establishes a procedure under
which "[t]he Office of Munitions Control will provide, upon written
request, a determination on whether a particular article is included on
the United States Munitions List." Questionable cases may be resolved
by following this procedure.
Assuming that encryption software does constitute "cryptographic
software" within the meaning of Category XIII(b), State Department
export licenses are required, REGARDLESS OF WHETHER THE ENCRYPTION IS
BASED ON THE DES ALGORITHM. The relevance of DES vs. non-DES lies in
the ease with which licenses can be obtained, not in whether licenses
are required.
B. The State Department's "public domain" exemption does not
apply to exports of "defense articles."
---------------------------------------------------------
Part 123 of ITAR contains rules governing export licenses for the export
of "defense articles." The basic rule is stated in Section 123.1(a) as
follows:
Any person who intends to export a defense article must obtain a
license from the Office of Munitions Control prior to the export
unless the export qualifies for an exemption under the provisions
of this Subchapter.
Part 123 sets forth a number of exemptions in sections 123.16 through
123.22. None is these exemptions covers the posting of cryptographic
software on a bulletin board.
Section 126.5 exempts from the licensing requirement any exports of
unclassified defense articles or unclassified technical data to Canada
for end-use in Canada or return to the United States. This exemption
would be potentially applicable only if the ONLY exports that might take
place as a result of the bulletin board posting were exports to Canada.
(See section 120.10, which defines "export" to include "[s]ending or
taking defense articles outside the United States in any manner.") In
any event, care would have to be taken to ensure that applicable
documentation requirements are met to invoke properly the exemption.
Part 125 of ITAR contains rules governing exports of technical data.
Section 125.1(a) provides:
The export controls of this part apply to the export of technical
data . . . . Information which is in the "public domain" (see
section 120.18) is not subject to the controls of this chapter.
Section 120.18 defines "public domain" as follows:
"Public domain" means information which is published AND WHICH
IS GENERALLY ACCESSIBLE TO THE PUBLIC:
(a) Through sales at newstands and bookstores;
(b) Through subscriptions which are available without restriction
to any individual who desires to obtain or purchase the published
information;
(c) Through second class mailing privileges granted by the U.S.
Government; or,
(d) At liberaries open to the public.
(Emphasis added.) This definition is a much more restrictive one than
the analogous Commerce GTDA regulation analyzed by Gilmore: a bulletin
board posting of information would not fall within ITAR's public domain
unless that posting qualified under paragraphs (a)-(d) of section
120.18. A posting would not appear to so qualify. (This memo does not
take any position on whether bulletin board posting would place
Commerce-controlled technical data into Commerce's public domain;
specific information about the technical data and the bulletin board
would be necessary.)
Regardless of how the ITAR "public domain" applies to bulletin board
postings in general, the posting of cryptographic software cannot fall
within the "public domain" provision, because, per section 125.1(a)
above, the "public domain" provision applies to "technical data."
Cryptographic software -- a "defense article" (see Section I.A above) --
does not constitute "technical data" under ITAR. More on that below.
The term "technical data" is defined in section 120.21 as follows:
"Technical data" means for purposes of this subchapter:
(a) Classified information relating to defense articles and
defense services;
(b) Information covered by an invention secrecy order;
(c) Information which is directly related to the design,
engineering, development, production, processing, manufacture,
use, operation, overhaul, repair, maintenance, modification, or
reconstruction of defense articles. This includes, for example,
information in the form of blueprints, drawings, photographs,
plans, instructions, computer software and documentation. This
also includes information which advances that state of the art of
articles on the U.S. Munitions List. This does not include
information concerning general scientific, mathematical or
engineering principles.
"Technical data" per this definition thus consists either of
information "relating to defense articles" (par. (a)) or information
directly related to the doing of things to "defense articles" (par. (c)).
[Paragraph (c) is not relevant here.] Since cryptographic software is
itself a "defense article," it cannot simultaneously qualify as
"technical data." Moreover, different ITAR Parts govern exports of
"defense articles" (Part 123) and exports of "technical data" (Part
125).
Of course, not all encryption materials (DES or otherwise) necessarily
take the form of "cryptographic software" controlled under Category
XIII(b) of the Munitions List. Non-Category XIII(b) materials will
qualify as "technical data" within the meaning of the section 120.21 and
will thus be eligible for "public domain" treatment if the specific ITAR
conditions apply.
II. Commerce Department Controls Over Cryptographic Software
--------------------------------------------------------
Section 370.10 of Commerce's Export Administration Regulations state the
general rule that Commerce does not control exports of State
Department-controlled items. Specifically, subsection (a) provides:
(a) U.S. Munitions List. Regulations administered by the Office of
Munitions Control, U.S. Department of State, Washington, D.C. 20520,
govern the export of defense articles and defense services on the U.S.
Munitions List.
Thus, Gilmore's statement that the State Department's concerns about
exports of crypt commands are "enforced" by Commerce is wrong.
What has complicated the picture and confused Gilmore is that Commerce's
Commodity Control List -- Commerce's counterpart to the United States
Munitions List -- contains a category 1527A covering "cryptographic
equipment . . . and software controlling or performing the function of
such cryptographic equipment." Gilmore identified this regulatory control
provision, but he misinterpreted it.
Gilmore found the note in category 1527A, which states that
Exporters requesting a validated license from the Department of
Commerce must provide a statement from the Department of State,
Office of Munitions Control, verifying that the equipment
intended for export is under the licensing jurisdiction of the
Department of Commerce.
Gilmore mistakingly says, however, that "we are not requesting a
validated license, we are using the general license, so this requirement
does not apply . . . ." Gilmore missed the 1527A heading: "Validated
License Required: Country Groups QSTVWYZ." These designated country
groups comprise every country in the world except Canada. Consequently,
a validated license issued by Commerce is required in order to make any
export of 1527A-controlled cryptographic software. And because a
validated license is required, exporters seeking such a license must,
per the note quoted above, submit a State Department statement
"verifying" that Commerce has jurisidiction over that cryptographic
software. Such a statement would generally take the form of an ITAR
section 120.5 commodity jurisdication determination.
In sum, unless the State Department has issued a statement verifying
Commerce jurisdiction over the cryptographic software that Gilmore has
in mind, Commerce's controls do not apply. And without such a
statement, Gilmore's analysis of section 379.3 of EAR (General License
GTDA) is completely irrelevant.
III. Conclusions
-----------
Gilmore's conclusion that the posting of cryptographic software to a
bulletin board places it in the public domain and thus exempts it from
export licensing controls is flat-out wrong. U.S. law is clear: in
order to export "cryptographic software" within the meaning of
Category XIII(b) of the United States Munitions List to any country
other than Canada, a State Department export license is required.
If there is any reason to believe or suspect that a non-U.S. or
non-Canadian national will gain access to that bulletin board, an export
to a third country should be assumed and a license is required..
If there is any question whether specific encryption software
constitutes "cryptographic software" within the meaning of
Category XIII(b), clarification can be obtained under procedures
established pursuant to section 120.5 of ITAR.
A determination from State under 120.5 that it does not have
jurisdiction is the prerequisite to bringing the control question into
Commerce's export regulations.
IT IS IMPERATIVE THAT NO DIGITAL EMPLOYEE ACT IN RELIANCE ON GILMORE'S
ANALYSIS OR HIS CONCLUSIONS.
--------End Forwarded Messagegnu@hoptoad.uucp (John Gilmore) (02/22/88)
I'm glad to see that a lawyer has finally looked over the analysis of
PD cryptographic software export controls that I did a while ago. I
still think we have a free country but will go look up the regulations
they quote, to make sure. It may be that before we post something, we
have to put it in a magazine or newsletter, or offer it on floppies to
anyone who sends in $5 -- no big deal. I would prefer to have a court
rule that posting something to 8000 machines, many of which are
public-access, and including it in a software library accessible to
anyone, is making it "freely available to the public". But for that to
happen, somebody will have to take somebody to court, and so far there
are no volunteers.
The point is that information which is freely available to anyone in
the US can be exported. If any Tom, Dick, or Harry in the states can
get it, there should be no grounds to hassle somebody over exporting
it.
Realize that the lawyer who came up with this opinion is paid by DEC to
keep DEC out of trouble. The safest thing to do, in the short term,
is to turn and run from any kind of trouble. I just think that the long
term trouble caused by only the government having privacy is worth
facing the short term trouble.
I'll have more to say later.
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com
"Watch me change my world..." -- Liquid Theatregwyn@brl-smoke.ARPA (Doug Gwyn ) (02/22/88)
In article <4106@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >I still think we have a free country ... I don't know how you got that impression. >The point is that information which is freely available to anyone in >the US can be exported. That's just what the DEC lawyers were telling you isn't so. There is an injunction against export of "defense materials", even if they are found growing on trees.
ps111wei@sdcc3.ucsd.EDU (Keith Messer) (02/23/88)
Now see here,
I propose that compilable source posted on a bullitin board
is not truly a computer program, but public domain technical data.
Truly, C source is not executable, and it is not in an executable
format as long as it has a mail header attached. It must be
has two barriers to qualifying as a computer program:
1) Compiler source is not compiled and;
2) it has a mail/bullitin board header attatched.
In other words, it is text describing how a program (ie.
potential defense material) may be created, and is really a sort of
outline of what a computer must do. I would also expect that source
code falls under the first ammendment, because there are a large
Number of people who read source rather than compiling it. I
personally have not compiled anything posted here, only read it out
of interest. I suspect that at least half of the people who read
this newsgroup, and probably 90% or so, are more interested in how
posted source works than compiling it on their own machines.
I'd be very interested in what the DEC lawyers had to say
about this, but sadly they have wimped out in advance. I think that
between first ammendment rights, an unclear distinction between
software and technical data, and the fact that in any case a DES
cracker will not hurt the United States, we have nothing to worry
about legally. Try to keep in mind the spirit as well as the letter
of the law, DEC! I'm sure that the NSA has someone reading this
newsgroup, and they haven't given us any problems yet. I personally
don't think they will. It would make a lot of sense right now to
make >sure< that United States national security cannot be biased by
our breaking the DES, because if I don't do it I'm fairly confident
that someone else will before the end of the year. And when it
happens, if the idea turns out not to be marketable, someone will
inevitably post a known-plaintext DES decrypter.
Does anyone in California want to give me a Summer job? I'm
going to go crazy if I spend another Summer sanding boats!
Keith Messer
P.S. Ok, ok, so how 'bout out of California? Oh well, I can see the
fiberglass dust already...wesommer@athena.mit.edu (William Sommerfeld) (02/23/88)
In article <4143@sdcc3.ucsd.EDU> ps111wei@sdcc3.ucsd.edu.UUCP (Keith Messer) writes: [trying to claim that [C] source code is not a computer program because it isn't directly executable] Yes, but that is a feature of an _implementation_ of the language, not of the language itself. There exist source-code level interpreters for C. \begin{salespitch} Saber Software makes a very good C interpreter (called `saber c'); send mail to kaufer@athena if you want info about it. It's amazingly useful for debugging, as it is _really_ source level debugging. Most importantly, you can dynamically link in precompiled modules and libraries. \end{salespitch} - Bill
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/24/88)
In article <4143@sdcc3.ucsd.EDU> ps111wei@sdcc3.ucsd.edu.UUCP (Keith Messer) writes: >... and the fact that in any case a DES cracker will not hurt the United States ... I agree with you, that the legitimate long-range interests of the nation and humanity in general are better served by accurate technical knowledge; if the DES is crackable, you really don't want to be using it for anything important (such as financial transactions). However, as it has evolved, the US government is able to get away with declaring things to be "in the national interest" that rationally are not. I don't have to give examples of this; you should already have them, if you regularly monitor the news. >I'm sure that the NSA has someone reading this newsgroup, and they haven't >given us any problems yet. You mean, they haven't given YOU any problems and they haven't made public postings. You don't know whom they have contacted personally. For the most part, there hasn't been much in this newsgroup to worry NSA, but a posted DES cracker would be another story.
daveb@geac.UUCP (David Collier-Brown) (02/26/88)
In article <4143@sdcc3.ucsd.EDU> ps111wei@sdcc3.ucsd.edu.UUCP (Keith Messer) writes: > I'd be very interested in what the DEC lawyers had to say >about this, but sadly they have wimped out in advance. >... Try to keep in mind the spirit as well as the letter >of the law, DEC! Not an unusual situation: companies often make the long-term mistake of trying to be like Caesar's wife and be above controversy. This was OK for an appendage of an emperor, but amounts to living in a dreamworld... If a person, male, female or corporate, actually expects to **do** anything in the observable world, controversy will follow. Statistically, every company above X employees has a manager or lawyer who will wimp out at the very mention of the CIA (US) or CSIS (Canada). --dave (is moral cowardice a survival trait?) c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
ruffwork@orstcs.CS.ORST.EDU (Ritchey Ruff) (02/28/88)
After reading the DEC statement, I see a "simple" way around it: (wait a minute while I open my mouth wide enough for my foot ;-) public domain can't be had unless it printed, it seems? Why doesn't someone start a mag. (good use for that Mac on your desk and the laserwriter down the hall) that is non-profit and call it "DES hackers!". Register yourself with yourself as a non-profit org (easy to do), then we just print the sources for the "public domain" DES in it and sell it for cost to whoever wants it. It's in print now, generally available, etc. so it's now legally in the public domain, so the other set of rules apply, etc, etc,... --ritchey ruff ruffwork@cs.orst.edu -or- ...!hp-pcd!orstcs!ruffwork
todd@uop.edu (Dr. Nethack) (03/03/88)
In article <2962@orstcs.CS.ORST.EDU>, ruffwork@orstcs.CS.ORST.EDU (Ritchey Ruff) writes: >that is non-profit and call it "DES hackers!". Gee, we should start a new newsgroup sci.des.crackers and the group could be moderated by the NSA! Not carried outside the us, (keep safe from communism) and other safety oriented measures...but.... if it is carried at berkeley... hmmm.. ;-) OH FUVG! at least let me get my flame suit on!!
colinm@runx.ips.oz (Colin McCormack) (03/04/88)
Anyone could easily write a program to implement DES, given a precise description of what DES *is*. Surely then the definition of DES is under the same caveat as a program which (purports to) implement(s) it. In which case, what *precisely* is DES? I seem to recall that the definition accepted by the DOD in the U.S. is related to the output of a certain encryption chip. What exactly is being restricted? Is an algorithm DES if it produces the same output for given input as some standard DES algorithm? - Then make your code differ in one value (remember designer drugs?). Is it DES if its I/O behaviour is predicted by some specification of DES algorithms? - Surely the description of that specification is either loose enough to be coded around or precise enough to be an algorithm in its own right. I think what is actually being restricted is the flow of DES chips, because they reduce the time for a brute force approach to cracking a transmission, and since (at least here) Automatic Teller Machines use DES, a lot of money is potentially at stake. The Rivest Shamir Adelson method is more secure, from memory - although it's under a patent restriction. One last thought, why not send the source in DES encrypted form with the key? Then the only people who can get at it will be those with an authorised copy (unless it's really not very secure :-) Colin McCormack.