From ncr-sd!hp-sdd!hplabs!ucbvax!BIOVAX.RUTGERS.EDU!hamm Mon Jan 11 00:27:16 PST 1988 I found the following of sufficient general interest to re-post to INFO-VAX. My apologies if you've already seen it elsewhere. Although the article deals mainly with DES, I wonder how the regulations discussed would apply to the CMU TCP/IP implementation, and the SPICE software in the DECUS library, both of which are available to the "public" at nominal cost in this country, but claim (last I saw, anyway) to be under export restrictions. I'd be interested to hear any qualified opinions on this. Greg ------------------------------------------------------------------------------ Gregory H. Hamm || Phone: (201)932-4864 Director, Molecular Biology Computing Lab || Waksman Institute/CABM || BITNET: hamm@biovax P.O. Box 759, Rutgers University || ARPA: hamm@biovax.rutgers.edu Piscataway, NJ 08854 * USA || ------------------------------------------------------------------------------ Date: Fri, 8 Jan 88 21:43:42 -0500 Reply-To: BITNIC FUTURE-L List Sender: BITNIC FUTURE-L List >From: Rayan Zachariassen Subject: Re: DES To: "GREG H. HAMM" In-Reply-To: <8801090124.AA07651@gpu.utcs.toronto.edu> After you read the following article (referred to earlier by Dennis Ferguson), hopefully the DES discussion will disappear from this list. Date: Mon, 26 Oct 87 17:18:36 PST >From: John Gilmore Message-Id: <8710270118.AA09965@hop.toad.com> Subject: Export control does *NOT* apply to publicly available software. Newsgroups: comp.society.futures To: info-futures@bu-cs.bu.edu References: <8710222017.AA01466@hadron.UUCP> <276@ddsw1.UUCP> I researched this topic pretty thoroughly last year, by going down to the local Federal Building and wading through the rulebooks in Commerce Dept. library. What prompted me to do it was that I had a PD DES, that I had posted to comp.sources.unix, which a Canadian reader claimed was in violation of export laws. Rich $alz took the info I got and talked with the NSA (US National Security Agency) and some Boston-area cryptographers. The upshot was that NSA never came up with anything that contradicted the rules I found, and Rich posted not only the DES code, for worldwide distribution, but also the "crypt breaker's workbench" that decrypts the ancient Unix "crypt" command. Now, the way things wag with NSA is that if you ask them "Can I do this?" the answer is almost always "No". What you have to say is "Show me the rules that say I can't do this. I have some that say I can." The courts have regularly ruled that the government cannot enforce a policy which is not written down and equally applied to everyone (it's called "secret law"). So if what *is* written down supports you, they are stuck with it. They can't secretly make new laws and tell you later that you broke them. Since everyone else on this topic is shooting off their mouth without having done any research (now we have *two* Canadians who are falsely telling us what the US export law is -- thanks guys!), I figured I'd better post my full references to make it credible. Save this message; if I ever leave the net somebody had better have a copy to shout down the clowns again. >From: gnu@hoptoad.uucp (John Gilmore) Newsgroups: net.crypt,net.sources.d,net.legal Subject: There are basically no export controls on public domain information. Message-ID: <1176@hoptoad.uucp> Date: 3 Oct 86 23:57:06 GMT I got into a hassle last month for posting a DES program to mod.sources because someone claimed that I was breaking the export control law. I spent the afternoon down at the Federal Building and discovered that export policy is in better shape than I thought. Basically, you can export any technical data to any destination if it "has been made generally available to the public in any form". This export is under a "general license" which is available to everyone without any paperwork. So, you should expect to see the DES posting again (it was canceled) and to see Crypt Breaker's Workbench on mod.sources soon. Here are the regs for all you policy hounds: Export Administration Regulations, Part 370.2, Definitions. "General License. A license established by the US Department of Commerce for which no application is required and for which no document is granted or issued. It is available for use by all persons, except those listed in and prohibited by the provisions of Supplement No. 1 to Part 388, and permits export within the provisions thereof as prescribed in the Export Administration Regulations. These general licenses are not applicable to exports under the licensing jurisdiction of agencies other than the Department of Commerce." Part 379.1, Definitions. "... All software is technical data." Part 379.2, Licenses to Export. "Except as provided in Part 370.3(a), an export of technical data must be made under either a US Department of Commerce general license or a validated export license. General licenses GTDA and GTDR apply to specific types of exports of technical data..." Part 379.3, General license GTDA: Technical Data Available to all Destinations. "A General License designated GTDA is hereby established authorizing the export to all destinations of technical data described in 379.3(a), (b), or (c) below: (a) Data Generally Available Data that have been made generally available to the public in any form, including-- (1) Data released orally or visually at open conferences, lectures, trade shows, or other media open to the public; and (2) Publications that may be purchased without restrictions at a nominal cost, or obtained without costs, or are readily available at libraries open to the public. The term "nominal cost" as used in 379.3(a)(2) above, is intended to reflect realistically only the cost of preparing and distributing the publication and not the intrinsic value of the technical data. If the cost is such as to prevent the technical data from being generally available to the public, General License GTDA would not be applicable. (b) Scientific or Educational Data ... (c) Patent Applications ..." ------ (end of first message) John here, talking to info-futures again. Chris Lewis (the first Canadian "expert") tried to pick the above to pieces, so I provided more explanation by private mail, now revealed to the info-futures readership for the first time ever! Date: Sun, 12 Oct 86 16:57:06 PDT >From: gnu (John Gilmore) Subject: Re: Export control revisited Chris Lewis is still somewhat concerned about export control. I will try to explain the things he mentioned in his message of 8 October. >> "General License. A license established by the US Department >> of Commerce for which no application is required and for which >> no document is granted or issued. It is available for use by >> all persons, except those listed in and prohibited by the >> provisions of Supplement No. 1 to Part 388, and permits export > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > what is this section about? It lists people who have abused the general license in circumstances where it does not apply (eg shipping Vaxen to Russia). The idea is that you are innocent until proven guilty with regards to general licenses. I looked in the supplement and it was a 3-page list of names and cities. I was not on it. :-) >> within the provisions thereof as prescribed in the Export >> Administration Regulations. These general licenses are not >> applicable to exports under the licensing jurisdiction of agencies >> other than the Department of Commerce." > ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ > DOC is not the only agency involved. I also got myself a copy of the regulations on cryptographic material export, but I didn't include it in my posting since it did not apply. It's listed under Part 399.1, supplement #1 (the Commodity Control List), "ECCN 1527A". It mentions that computers when combined with cryptographic software are covered under this ECCN, and says "Technical Note: No technical data or software controlled under this ECCN may be exported or reexported under General License GTDR." HOWEVER, we are exporting under General License GTDA, not GTDR, and this is a valid distinction. There is nothing in this ECCN section that precludes shipping cryptographic technical data (e.g. software) under general license GTDA. It also says, "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." (emphasis mine) However, we are not requesting a validated license, we are using the general license, so this requirement does not apply either. In summary, I believe that the provisions of ECCN 1527A do not apply to public domain software, and we are OK. (I don't know of any other ECCN sections that apply either.) >> Part 379.3, General license GTDA: Technical Data Available to all >> Destinations. >> "A General License designated GTDA is hereby established >> authorizing the export to all destinations of technical data >> .... >> >> (1) Data released orally or visually at open conferences, >> lectures, trade shows, or other media open to the public; and >> >> (2) Publications that may be purchased without restrictions >> at a nominal cost, or obtained without costs, or are readily >> available at libraries open to the public. > >This, in turn: > > 1) Has *this* DES program been formally published before? > 2) Can it legally be? Journals are supposed to be reviewed prior > to publication by one of the security agencies. We're a loophole. > 3) From another tack: can you make a DES program PD? (1) You elided the relevent section of the general license definition. "(a) Data Generally Available: Data the have been made generally available to the public IN ANY FORM, including... (1) and (2)...". (emphasis mine.) If something has been placed into the public domain and its location advertised to the Usenet community, or placed into a publicly accessible bulletin board, or posted to the Usenet, I claim that it has been made generally available to the public. (1) and (2) are not the only ways something can be made available to the public; they are just examples. (2) You can't be expected to know how things work in the U.S., being Canadian, but there is NO requirement that "journals are supposed to be reviewed prior to publication". We have a free press here. They tried to impose something like this and it didn't work. There is a "voluntary" system whereby authors can submit manuscripts to the NSA for review, but you are not even bound by the result -- they can only make suggestions. Mostly this is so they can recommend that you delete certain phrases that might give away what they are working on, and you are supposed to feel patriotic enough to go along. Presumably they could also try to go to court to stop you from publishing, but I don't think that has happened to any paper that has been voluntarily submitted under this program. (They did go to court against the magazine that published the "how to build an atom bomb" article.) You may be confused between mandatory review of journals and the Defense Department's right to review articles by people who they fund. If you are doing government-sponsored research, they can write the contract such that they get to OK any release of information derived from the sponsored research. But if I invent something on my own, without gov't money, I can publish it. (3) Public Domain-ness is a state of ownership. Since you can certainly own a DES program (e.g. AMD owns the copyright of the 8068 DES chip; ATT owns crypt(1)), you can also renounce its ownership and place it into the public domain. >You didn't include anything from 370.3 (or is that a typo?) either. It was not a typo. I don't have a copy of it here, but I don't think it applies to us. It's part of the "General Policy on Exports" section. >If this program were to be published in a technical magazine (presumably >safest in a real journal, not necessarily BYTE), then I'd feel safe >because they've already had approval. BYTE published one or two DES programs >ages ago, but this was before the NBS standard was formalized. Presumably >you could publish *that* program (6502 assembler), but not anything written >since then. I haven't seen a DES program since (though, I don't read all >that many journals...) This objection is covered above -- there is no required government review of publications here, and no government approval is required to publish. >I realize perfectly well that a court challenge on this would probably >find in our favor - as in, is DES in software really DES? But, I want >to ensure that we stay well clear of the shadow (if not the substance) >of the law. Actually, this is not relevant. The export control regs don't mention DES at all. They say "cryptographic equipment...designed to ensure secrecy of communications...or of stored information...and "software"... performing the functions of such cryptographic equipment", and then make a few exemptions for things like simple scrambled voice, video, or fax. >I can't help remembering the export restrictions on crypt (which, I believe >are still in effect *even tho* Enigma has been declassified for years), >AT&T's security package, Motorola and Intel's encryption boards etc. >I remember seeing discussions in trade journals 2-4 years ago about DES >export restrictions, code-breaking discussions, other more recent encryption >methods, but I can't remember where. None of the above stuff is "technical data generally available to the public", so it cannot be exported under the GTDA general license. Note that journal articles like the AT&T Tech Journal one on breaking crypt are generally available to the public, and they are being exported without trouble. Ditto for _Cryptologia_. It *DOES* take an export license to export non-public technical data, e.g. the Unix crypt command (licensed software), encryption boards (hardware, not technical data), etc. I must say that I felt the same way you do about this -- I had a general feeling that exporting this stuff was illegal, even though I thought it should be legal -- until I spent the time to research it. My opinion of the people who wrote US export law has gone up significantly. They really believe that if the US "public" can get it, it is exportable. FYI, here is the definitive story on how the "export restrictions on crypt" came about, from Dennis Ritchie himself. As you can see, no government agency ever said it could not be exported; AT&T and DEC simply decided that applying for an export license was too much trouble. I've also included a message from Gordon Moffett who says that Amdahl is now exporting Unix with the crypt command without trouble. >From dmr@research.UUCP Mon Sep 17 22:15:46 1984 Path: CSL-Vax!decwrl!decvax!mcnc!unc!ulysses!allegra!alice!research!dmr >From: dmr@research.UUCP Newsgroups: net.crypt Subject: export controls Message-ID: <1041@research.UUCP> Date: 18 Sep 84 05:15:46 GMT Posted: Mon Sep 17 22:15:46 1984 As has been said, there is indeed a special "International Edition" of System V that differs from the ordinary system in that it lacks the crypt command, the encrypting features of ed and vi, and the encrypt entry of crypt (3). The crypt entry, which is used for passwords, is there, as is the underlying DES algorithm. Here's how it happened. About a year ago, I got mail from Armando Stettner saying basically, "Do you know of any problems with exporting crypt? Our lawyers [at DEC] are worried about it." I replied that such worries were utterly unfounded for a variety of sensible reasons. Now, as it has turned out, DEC was very justified in worrying about export controls in general; they have recently been fined (I think) $500,000 for the Vaxen that almost got sent to Russia. I conjecture that the earliest stages of this or a similar incident were already in progress and they were trying to be extra careful when they learned about crypt. At any rate, the DEC lawyers communicated their fears to AT&T, and the AT&T lawyers, equally cautious, sought government advice. The problem, you see, is that cryptographic materials are under export control. There is a thing called the Munitions Control Board that worries not only about machine guns going to Libya, but also about the crypt command going to England. In practice, the enforcement is done by the Commerce department. AT&T had a meeting with Commerce, the MCB, and NSA. The upshot was that they decided it would be simplest all around just not to export the crypt command. The gov't would almost certainly have granted the license, but (probably wisely) AT&T decided it wasn't worth the hassle. In technical terms, the situation is ludicrous. The encrypt subroutine is distinguished mainly by the excruciating care I took to make it an exact transcription of the algorithm published in the Federal Register, and by its slowness. NBS, the caretaker of DES standardization, is explicit that software implementations cannot be certified, so in that sense encrypt is not "real" DES. The underlying subroutine is still there, only the simple command that uses it is missing. So there is actually nothing to protect, and even if there were, it's not protected. Nevertheless, in the present situation we officially don't need an export license, whereas with the crypt command we would. In political terms, AT&T probably could have done better. Conservative and careful, they called a big meeting at which no one could possibly have put forward anything but official positions about encryption programs. Private checking with well-placed people in the appropriate agencies might well have done the job. But who knows? Dennis Ritchie ----- In article <3140@amdahl.UUCP> Gordon Moffett writes: Our Corporate legal advisor says that the restrictions against exporting encryption stuff has been lifted. We used to have two UTS's: one with the crypt(3) stuff for domestic customers, and one without export. We no longer distiguish between the two -- we now ship everything to non-USA customers just as to the USA sites. I've already gotten one letter about this, asking me for further confirmation that this is ``true''. First, PLEASE DON'T ASK ME! Talk to *your* companies' legal advisors, or to the Federal Government directly. Second, I am sure we would hear about it from the Federalees if our Corporation were making a mistake .... -- Gordon A. Moffett ...!{ihnp4,seismo,hplabs}!amdahl!gam [Back to Chris's comments: -- gnu] >The definitive answer would be to see whether the current listing of >restricted items includes DES, and in what forms. I don't think excerpts >from a different set of legislation is sufficient to answer this question. >Further, there *may* be a difference between "legislation" and "regulation" >here. DES restriction might *not* be enshrined in legislation, but come >out of some other department's regulatory powers. The second paragraph >I've quoted still leaves that whole question open. I have spent the time researching it, and I think it's OK to export. If you still think differently, please give details of the regulations or laws involved. I'm not interested in "maybes"; I have an answer that came straight from the rule books, and won't be swayed from it by anything less definitive. ------ I N T E R O F F I C E M E M O R A N D U M Date: 3-Mar-1989 02:23pm EST From: Tom Gaudette GAUDETTE Dept: DECUS Library Tel No: 617-480-3636 TO: See Below Subject: RE: Export Controls Having sent the Jamie Hanrahan/Jack Gilmore message and along with a few abstracts of some programs we currenty call 'restricted' to a contact in DEC's Corporate Export/Trade Group, I have gotten the following reply. The first part is this Export Manager's summary back to me, followed by the Corporate legal analysys. I interpret this to support and enforce the Library's current practice. Shall we open this up to comments before doing anthing with DECUSserve? Tom Distribution: TO: Ralston Barnard ( BARNARD ) TO: Frank Bush ( BUSH ) TO: Glenn Everhart ( EVERHART ) TO: Ron Frederick ( FREDERICK ) TO: Tom Gaudette ( GAUDETTE ) TO: Jeff M Gold ( GOLD ) TO: Robert Hassinger ( HASSINGER ) TO: Larry W. Hicks ( HICKS ) TO: David Hittner ( HITTNER ) TO: Michael Kaczmarek ( KACZMAREK ) TO: Robert K Krieg ( KRIEG ) TO: Bart Z. Lederman ( LEDERMAN ) TO: Carl Lowenstein ( LOWENSTEIN ) TO: Michael McIntyre ( MCINTYRE ) TO: M. Edward (Ted) Nieland ( NIELAND ) TO: Pat Patel ( PATEL ) TO: Andy Powderly ( POWDERLY ) TO: Anthony E. Scandora, Jr. ( SCANDORA ) TO: David Schmidt ( SCHMIDT ) TO: Ted Smith ( SMITH ) TO: Jack Stevens ( STEVENS ) TO: David Todd ( TODD ) TO: Robert "Just Bob" Uleski ( ULESKI ) Dear Sir, I have attached a copy of Tom Ehrgood's response (Feb 88) to John Gilmore's memo (Oct 87) about cryptographic software and export controls. Tom's response is still valid and it is important that it receives a wide circulation. Regarding SPICE, this software falls within the Export Administration Regulations under the jurisdiction of the Commerce Department. The Commodity Control number is 1355A. ECCN 1355A covers the following: Equipment for the manufacture or testing of electronic components and materials; and specially designed components, accessories and "specially designed software" therefor. This includes: Computer aided design (CAD) equipment for transforming schematic or logic diagrams into designs for producing semiconductor devices or integrated circuits, having any of the following functions: (a) Storage of pattern cells for subdivision of integrated circuits; (b) Scaling. positioning or rotation of pattern cells; (c) Interactive graphic capabilities; (d) Design rule and circuit checking; (e) Circuit layout modification of the arrangement of the elements; Software that can perform any of these functions, or that can be used for transient analysis, for logic analysis or logic checking, for automatic routing or cell placement, for the generation of test vectors or for process simulation is "specially designed software" controlled for export. It is classified as GTDR, not GTDA. SPICE, ADORE and PROUD all fall within 1355A and require an individual validated license (IVL) approval for export and re-export to DECUS members. The University of California at Berkeley concur with this assessment hence the "restriction" clause included with their Submission. I hope this clarifies the situation. Regards, 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 the 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 exports of that software are no longer controlled. 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 license 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." (Different ITAR Parts govern exports of "defense articles" (Part 123) and exports of "technical data" (Part 125)). Of course, not all DES encryption materials necessarily take the form of "cryptographic software" controlled under Category XIII(b) of the Munitions List. These other materials will generally qualify as "technical data" within the meaning of the section 120.21 and 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, which covers "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 a 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 the section 379.3 (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. 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. Distribution: