From news.admin Tue Oct 15 16:47:25 1991 Xref: news-server.csri.toronto.edu news.admin:17839 sci.crypt:6393 comp.org.eff.talk:4917 misc.legal.computing:155 Path: news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!ucbvax!ulysses!ulysses.att.com!smb From: smb@ulysses.att.com (Steven Bellovin) Newsgroups: news.admin,sci.crypt,comp.org.eff.talk,misc.legal.computing Subject: Re: U.S. Cryptographic export restrictions Message-ID: <15651@ulysses.att.com> Date: 14 Oct 91 19:33:04 GMT References: <2047@array.UUCP> <1991Oct13.142314.7504@newshost.anu.edu.au> <1991Oct14.154257.20310@newshost.anu.edu.au> Sender: netnews@ulysses.att.com Lines: 76 In article <1991Oct14.154257.20310@newshost.anu.edu.au>, cmf851@csc2.anu.edu.au (Albert Langer) writes: > Frankly I don't believe that you, or any of the others that have > been pushing this issue have the SLIGHTEST interest in or intention of > conclusively settling it that way - it's some kind of "urban myth" > that you would RATHER keep speculating about. THAT is the problem, > not the expense of lawyers. If we're going to resort to name-calling, I'll drop out of this discussion, thank you. But let me pose this question to you: why should any number of UNIX system vendors go to great lengths to prepare domestic and export versions of their systems when they could simply include published code. Consider Sun, for example. Their ``encryption kit'' sells for $50, a price that would barely cover their distribution costs, if at all. Do you really think they'd rather sell a no-profit item when they could just bundle it in? Ditto DEC, ditto AT&T, ditto just about everyone else in the business. The expense of lawyers comes in not when you try to understand and act on the regulations, but in defending yourself if someone in the government decides you're wrong. I should add that the attempt has been made. I've been told (by folks who should know) that MIT discussed with the government their arrangements for distributing Kerberos. So it's not just hearsay or urban myth. As for me, personally? I have no code to give away, putatively restricted or not. I don't own a machine of my own; the only facilities I have for developing anything are AT&T-owned, so I'd have no right to give code away no matter what it was for. (I could, I suppose, produce some hand- written algorithms and paper-mail them to someone.) > The fact is you prefer to broadcast to the world speculations > about what you HOPE to find in some "paper" in your office tomorrow > rather than pay the slightest attention to the plain words of the > U.S. International Traffic in Arms Regulations. Clearly the issue > here is religious, or at least mythological, not legal. Do you write ``HOPE'' [sic] to imply that I was deluding myself, but desparately grasping at straws to back up my earlier statement? Bull. The ``paper'' I referred to is ``Public Cryptography, Arms Export Controls, and the First Amendment: A Need for Legislation'', by Kenneth J. Pierce, Cornell International Law Journal, Vol 17:197, 1984, pp 197-236. It won the 1984 Earl Warren Prize for the ``paper best exemplifying the late Chief Justice's commitment to civil rights''. Frankly, I have somewhat more confidence in Pierce's reading of the regulations than I have in my own. In any event, after citing the same section 120.18 that you quote, he continues, ``This exemption, however, is not self- executing; it must be applied for.'' The footnote reads as follows; I'm using \(sc for the section squiggle: 22 C.F.R. \(sc 125.20(a)(1983). The burden of obtaining government approval of an ITAR license or of an ITAR exemption is on the person or company seeking publication. 22 C.F.R. \(sc 125.11(a)(1) n.3 (1983). The Murray Hill technical library does not appear to have that section of the Code of Federal Regulations; I may or may not wander over to the local lawyers and see if there's an easily accessible copy. Again, can we please avoid the name-calling and aspersions? You've obviously done much more homework than most folks; kindly grant us the right to come to different conclusions based on the data we do have. And as for your comment the other day about whether or not the U.S. government was stupid enough to behave in that fashion -- given the story about Ken Thompson and the chess machine, or the story about the Soviet nuclear reactor, I have to conclude that yes, it can be that stupid.... --Steve Bellovin P.S. Please don't read the above as indicating I agree with the law or the regulations. I don't, and I've said so in the past in this forum. From news.admin Tue Oct 15 16:47:53 1991 Xref: news-server.csri.toronto.edu news.admin:17841 sci.crypt:6394 comp.org.eff.talk:4918 misc.legal.computing:156 Newsgroups: news.admin,sci.crypt,comp.org.eff.talk,misc.legal.computing Path: news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu!cs.utexas.edu!utgpu!dennis From: dennis@gpu.utcs.utoronto.ca (Dennis Ferguson) Subject: Re: U.S. Cryptographic export restrictions Message-ID: <1991Oct14.201359.8360@gpu.utcs.utoronto.ca> Organization: none at all References: <2047@array.UUCP> <1991Oct13.142314.7504@newshost.anu.edu.au> <15646@ulysses.att.com> <1991Oct14.154257.20310@newshost.anu.edu.au> Date: Mon, 14 Oct 1991 20:13:59 GMT In article <1991Oct14.154257.20310@newshost.anu.edu.au> cmf851@csc2.anu.edu.au (Albert Langer) writes: >125.1 >(a) 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 sub-chapter. > >There is no way you can interpret the plain words "...Information which >is in the 'public domain' ... is not subject to the controls of >this sub-chapter." as meaning that you still have to apply for a >licence and cite some publication - under what regulations would you >apply? Certainly not the International Traffic in Arms Regulations >since that is sub-chapter M, nor the Export Administration Regulations, >which explicitly provide a GTDA licence WITHOUT application under >similar circumstances. I don't want to debate this, but did want to point out why I personally would see a lawyer rather than taking your word for it. As I understand it, your arguments are that: (1) The "public domain" exemption in part 125 applies to all information, not just "technical data". DEC's lawyer disagrees with this because the exemption is in part 125, and part 125 explicitly applies to "technical data" only. (2) That while "cryptographic software" certainly is a "defense article" (we know this is true because 120.7 defines "defense article" as any item in the munitions list, and "cryptographic software" is an item mentioned in the munitions list), it is also "technical data" so that part 125 applies to it as well. DEC's lawyer, on the other hand, says that "cryptographic software" can't be a "defense article" and "technical data" simultaneously, and since it is certainly a "defense article" by virtue of its inclusion in the munitions list, it isn't "technical data" and part 125 does not apply. So what it comes down to is we have you saying that (1) part 125 applies to "defense articles" as well as "technical data", and (2) "cryptographic software" is "technical data" even though it is also a "defense article", while DEC's lawyer says that neither of these assertions is true. So what we have is you and DEC's lawyer coming to different conclusions based on a reading of the same material. So who should I believe, DEC's lawyer or you? I think I'd rather get another opinion, thanks. Dennis Ferguson University of Toronto From news.admin Sat Oct 19 01:46:13 1991 Path: news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!swrinde!ucsd!nosc!crash!cmkrnl!jeh From: jeh@cmkrnl.com Newsgroups: news.admin Subject: Re: U.S. Cryptographic export restrictions Message-ID: <1991Oct18.160835.4@cmkrnl.com> Date: 18 Oct 91 23:08:35 GMT References: <17517@smoke.brl.mil> <1991Oct14.164119.20717@newshost.anu.edu.au> <1991Oct16.213558.19013@sci34hub.sci.com> <1991Oct17.162951.28352@newshost.anu.edu.au> Organization: Kernel Mode Consulting, San Diego CA Lines: 28 In article <1991Oct17.162951.28352@newshost.anu.edu.au>, cmf851@csc2.anu.edu.au (Albert Langer) writes: > In article <1991Oct16.213558.19013@sci34hub.sci.com> gary@sci34hub.sci.com > (Gary Heston) writes: > >>I have enough to do with my time, without having the FBI or SS investigate >>me, seizeing all my computer stuff (not to mention the field day they'd >>have here at work), and doing more damage to my finances than I already >>have this year with the legal expenses I'd pay fighting them to get just >>my own stuff back, not to mention needing another job after getting the >>company shut down for a month or so. > > Wow, what an exciting life you must lead with the FBI and SS just waiting > to pounce on you to search for "public domain" software that you might > have got from some public library and exported. Al, please go to a public library and find the September, 1991 issue of _Scientific American_. Read the article "Civil Liberties in Cyberspace" by Mitchell Kapor. THEN tell us that anyone who wants to export p-d software that just happens to be on the U.S. Munitions List has *absolutely nothing* to worry about, just because current law can be interpreted to mean that it's okay for them to do so. Yes, we live in exciting times. --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA Internet: jeh@dcs.simpact.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com Uucp: ...{crash,eisner,uunet}!cmkrnl!jeh From news.admin Mon Oct 21 16:34:16 1991 Xref: news-server.csri.toronto.edu news.admin:17986 sci.crypt:6462 misc.legal.computing:238 comp.org.eff.talk:5065 Path: news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uwm.edu!linac!att!att!ulysses!ulysses.att.com!smb From: smb@ulysses.att.com (Steven Bellovin) Newsgroups: news.admin,sci.crypt,misc.legal.computing,comp.org.eff.talk Subject: Re: U.S. Cryptographic export restrictions Message-ID: <15706@ulysses.att.com> Date: 21 Oct 91 16:18:54 GMT References: <1991Oct19.192053.17624@nntp.hut.fi> <1991Oct21.141925.16401@newshost.anu.edu.au> Sender: netnews@ulysses.att.com Lines: 50 In article <1991Oct21.141925.16401@newshost.anu.edu.au>, cmf851@csc2.anu.edu.au (Albert Langer) writes: I give up; this is my last message shouting into the wind. You've won; please export whatever you want... > > I have seen messages from Rich Salz, rather terse messages, perhaps > composed during an occasional break taken from moderating the massive > volume of software pouring through comp.sources.unix, and I have seen > messages from various people reporting what they believe they have heard > from other people about things told to MIT. You labeled my statement -- when I quoted someone from MIT -- as ``double hearsay'', implying -- nay, stating -- that you wouldn't accept it if my source posted directly to the net. For what it's worth, I think that my source was at the meeting, or saw the messages; he was involved with Kerberos as part of his work on Project Athena. Besides, we're not talking rules of evidence here. We're trying to establish whether or not the U.S. government enforces certain policies, despite your reading of the regulations. > "Secret law" is unenforceable in the United States. The U.S. Government > takes it's position on what is export controlled through published > regulations such as the International Traffic in Arms Regulations and > the Export Administration Regulations (which are themselves subject > to review by the courts). You're quite correct about the unenforceability of secret law. However, the law is not a computer; you don't feed in a text file containing the statutes and regulations, and another file describing actions, and wait to see if an indictment pops out. In the real world, there are advisory opinions, and sometimes even negotiations. In a case like this, where the government may be more interested in preventing an action than in prosecuting aftewards, it's certainly in their interest to try to persuade you otherwise. (Note that I'm not expressing an opinion on whether that's right or wrong; I'm simply saying that it happens.) Of course, it's entirely possible that MIT was bluffed, and that there wouldn't have been a prosecution. I have no way of knowing. On the other hand, not all indictable offenses are prosecuted -- and the decision criteria can be as simple as ``our budget will let us handle this case or that, and this one isn't important enough''. Look -- your basic claim is that the regulations now permit export. I, and several others, have posted reasons why we think you're wrong. In my case, it's partly because someone I know personally was told otherwise by a representative of the U.S. government. If you have some evidence that you're right -- as opposed to your own reading of the regulations -- you're welcome to post it. Otherwise, please go away on this topic, at least on sci.crypt. From sci.crypt Mon Oct 21 16:46:38 1991 Xref: news-server.csri.toronto.edu sci.crypt:6443 news.admin:17938 misc.legal.computing:214 comp.org.eff.talk:5018 Path: news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cis.ohio-state.edu!ucbvax!ulysses!ulysses.att.com!smb From: smb@ulysses.att.com (Steven Bellovin) Newsgroups: sci.crypt,news.admin,misc.legal.computing,comp.org.eff.talk Subject: Re: U.S. Cryptographic export restrictions Message-ID: <15693@ulysses.att.com> Date: 18 Oct 91 19:16:24 GMT References: <1991Oct16.213558.19013@sci34hub.sci.com> <1991Oct18.162232.10563@newshost.anu.edu.au> Sender: netnews@ulysses.att.com Lines: 37 In article <1991Oct18.162232.10563@newshost.anu.edu.au>, cmf851@csc2.anu.edu.au (Albert Langer) writes: } What is missing from the other side in this debate is a single } scrap of evidence from anyone that the U.S. Government either claims } it can control the export of public domain information or attempts } to do so. So far the claims have come solely from self-appointed } net police, not the U.S. Government and I have quoted the plain } words of the relevant U.S. Government regulations to show the } Government specifically rejects any such claim. I'd say you missed the part of an earlier posting of mine that mentioned it; however, since you responded to that paragraph, I can't make that excuse for you. The Kerberos folks *did* check with government officials on distribution mechanisms. The bones distribution was the result of that contact. To be sure, I'll quote myself -- and you -- again. >I should add that the attempt has been made. I've been told (by folks >who should know) that MIT discussed with the government their >arrangements for distributing Kerberos. So it's not just hearsay or >urban myth. I have no criticism of the MIT arrangements for distributing Kerberos. They strike me as quite a reasonable way to release some software to the U.S. "public domain" (in the ITAR sense) without any possibility of being accused of having simultaneously exported it (as might be the case if they posted it to a sources group or initially released it WITHOUT such warnings in an ftp area accessible to foreigners). Hearsay? Perhaps legally -- I wasn't at the meeting. But I heard the story from someone whom I believe was there. By the way, have you ever worked for a software development organization? Do you have any idea just how much trouble it is to prepare an entire release, in two versions? I've been there, and I've been at lots of meetings, including some with management present, and you wouldn't believe the pain the export rules have caused. AT&T's lawyers aren't complete fools, you know... From dennis Mon Oct 21 23:22:21 EDT 1991 Replied: Mon, 21 Oct 91 14:02:32 -0400 Replied: Dennis Ferguson Return-Path: relay.cs.toronto.edu!MrBill.CAnet.CA!dennis Received: from relay.cs.toronto.edu ([128.100.3.6]) by smoke.cs.toronto.edu with SMTP id <1151>; Mon, 21 Oct 1991 12:17:20 -0400 Received: from MrBill.CAnet.CA ([128.100.102.9]) by relay.cs.toronto.edu with SMTP id <150291>; Mon, 21 Oct 1991 12:16:59 -0400 Received: by MrBill.CAnet.CA id <105468>; Mon, 21 Oct 1991 12:15:04 +0100 From: Dennis Ferguson To: moraes@cs.toronto.edu Subject: Re: export of cryptographic info Cc: cks@utcs.utoronto.ca, clewis@ferret.ocunix.on.ca, rayan@cs.toronto.edu Message-Id: <91Oct21.121504bst.105468@MrBill.CAnet.CA> Date: Mon, 21 Oct 1991 07:14:54 -0400 Mark, I have a 1986 copy of ITAR (the State department regulations) somewhere, though I'm damned if I'm going to type them in. There is definitely an exemption for Canada in ITAR as well, in the case of non-classified defense articles and technical data. I don't know that Canada has any regulations against reexport except COCOM, however, and the original exporter from the US appears to be responsible if stuff gets reexported from Canada, so this may act as a deterent to export here as well. I think the whole issue of the applicability of the public domain exemption is whether "cryptographic software" can be a "defense article" and "technical data" simultaneously, since the public domain exemption is in part 125 which only applies to "technical data". The DEC lawyer says "cryptographic software" can't be both simultaneously, and hence part 125 does not apply, but note that this is only his opinion. The law doesn't say this. Note also that the DEC lawyer is schizophrenic about this, in that he first claims that part 125 doesn't apply to "cryptographic software", but later claims that export is assumed if the software can be accessed by foreign nationals, something that would only be true if part 125 applied to "cryptographic software" since that is where the latter restriction is. Note that the MIT policy on Kerberos (putting it in an ftp area where foreigners can see it, but warning against export) is consistant with "cryptographic software" being a "defense article" only, since it complies with part 123 (which controls "defense articles") but not part 125 (which has the restriction about showing stuff to foreigners). If the government told MIT this was okay then they probably think that "cryptographic software" isn't "technical data" either. Dennis From news.admin Wed Oct 23 15:48:32 1991 Xref: news-server.csri.toronto.edu sci.crypt:6477 news.admin:18006 misc.legal.computing:253 comp.org.eff.talk:5103 Path: news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ames!ucsd!qualcom.qualcomm.com!qualcom.qualcomm.com!karn From: karn@qualcom.qualcomm.com (Phil Karn) Newsgroups: sci.crypt,news.admin,misc.legal.computing,comp.org.eff.talk Subject: Re: U.S. Cryptographic export restrictions Message-ID: <1991Oct22.162742.20083@qualcomm.com> Date: 22 Oct 91 16:27:42 GMT References: <17517@smoke.brl.mil> <1991Oct14.164119.20717@newshost.anu.edu.au> <1991Oct21.201017.9087@visix.com> Sender: news@qualcomm.com Reply-To: karn@chicago.qualcomm.com Organization: Qualcomm, Inc Lines: 50 Nntp-Posting-Host: qualcom.qualcomm.com In article <1991Oct21.201017.9087@visix.com>, amanda@visix.com (Amanda Walker) writes: |> Mr. Langer, I have not only read the law in question, I have spoken |> directly with the U.S. customs service about exporting software which |> could be used for encipherment. I specifically asked about *both* |> proporietary and public domain implementations, since I hoped, as you |> do, that ITAR would not cover PD software. I was told that all export |> of cryptographic software, regardless of its status as public domain, |> required a munitions export license, with a single exception. [...] Here's one data point, for what it's worth. Some years ago I wrote a DES implementation and placed it (source and object) into the public domain. (Actually, I started with PD DES function code by Richard Outerbridge and several others, hacked it heavily and tuned it for speed, ported it to the PC, and created a "des" command that is a compatible, functional superset of the SunOS "des" command.) I've explicitly disclaimed all ownership and control over this software - anyone may use it for any purpose without my permission. My code has been available for quite some time by anonymous FTP from numerous sites, some of which are outside the US (of course, I have no idea who put it on those non-USA sites!) One indication of how far and wide it has propagated is that a friend found it incorporated into a disk of programs sold for pirating the GI Videocipher II satellite descrambling system. No one from the government has EVER questioned me about this code. I did hear a rumor from a friend who works in the "intelligence community" that someone did write a letter to the US Commerce Dept accusing me of "treason" for this act, but nothing ever came of it. Apparently this particular complaint was politically motivated since the writer was believed to be a radio amateur who was opposed to the creation of a no-code amateur radio license, a cause I was strongly supporting in public at the time. (To this day I do not know the identity of the letter writer, or the actual contents of the letter). So there are three possibilities: 1. The appropriate parties in government still haven't heard of my code and its widespread dissemination outside the US. 2. They've heard, but they don't care. 3. They've heard, they care, but they don't think they could successfully prosecute me for ITAR violations. Any guesses? Phil From news.admin Mon Oct 28 23:51:43 1991 Xref: news-server.csri.toronto.edu news.admin:18048 sci.crypt:6497 Path: news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!fernwood!portal!cup.portal.com!Tony_S_Patti From: Tony_S_Patti@cup.portal.com Newsgroups: news.admin,sci.crypt Subject: Re: U.S. Cryptographic export restrictions Message-ID: <49294@cup.portal.com> Date: 27 Oct 91 03:11:59 GMT References: <1991Oct19.192053.17624@nntp.hut.fi> <1991Oct23.031155.29060@sq.sq.com> <9686@cactus.org> Organization: The Portal System (TM) Lines: 182 While there have already been 69 messages in this thread, I am, I believe, the only person to join the discussion who has received validated DSP-5 export licenses from the U.S. Department of State (I have received 6) -- and these were approved without my having to pay to register as an exporter. Before I begin, let me state unequivocally that I have always believed that the First Amendment supersedes ITAR. In fact I asked [via certified mail with return receipt] the Department of State to respond in writing if they agreed or disagreed with that statement, and they chose instead NOT to respond at all. I had 6 licenses approved in the April 87 - July 87 time period for the export of FREE copies of a Galois Field based cryptosystem with complete source code in Pascal (and a maximum functional keyspace of 249 bits; my more recent software which appears in _Cryptosystems Journal_ supports megabit-sized keys). I don't need a degree from the Wharton School of Business [but I have one anyway] to know that FREE crypto software has no economic value! My offer of FREE cryptosystems has appeared in a number of publications (Cryptologia, Corporate Security Digest, Circuit Cellar Ink, The EDP Auditor Update, IEEE Communications Magazine, among others). This list is indicative of the wide range of uses that cryptology has in the modern world. These licenses were granted after I appealed the first Commodity Jurisdiction (CJ) determination that I received and after I met with 2 NSA employees (the same date I met with these 2 employees a letter was also sent to me from the U.S. Internal Revenue Service stating that I owed additional taxes - - coincidence that the only time I met with the NSA was the only time [before or since] I was sent such a letter from the IRS -- on the same exact day??? And by the way, they agreed after the obligatory correspondence that I did NOT owe additional taxes). I specifically point out that a cryptosystem such as mine which utilizes a pair of matrices containing integers as the keys traces its roots back to Prof. Lester Hill's papers in 1929 and 1931 -- hardly "state-of-the-art" high-technology! For the legal and policy background on this issue I recommend "Public Cryptography, Arms Export Controls, and the First Amendment: A Need for Legislation" in _Cornell International Law Journal_, Volume 17, 1984, pages 199-236, which I have posted about some time ago. The only court case which is related to this topic is U.S. of A. vs Edler Industries [they worked on Polaris and other missile programs but the carbon/carbon technology was dual-use], see 579 Federal Reporter 2d Series, pages 516-522, a decision rendered by the U.S. Court of Appeals on July 31, 1978. Notable quotes from this decision are: "If information could have both peaceful and military applications, defendant must know or have reason to know that its information is intended for prohibited use." I REALLY LIKE THE ABOVE JUDICIAL QUOTE. "... evidence concerning nonmilitary applications is relevant to the question of scienter, i.e., whether a defendant knew or should have known that the recipient of the exported information would use the information to produce or operate Munitions List articles." "In the context of the regulatory framework, an expansive interpretation of technical data relating to items on the Munitions List could seriously impede scientific research and publishing and the international scientific exchange." "If the information could have both peaceful and military applications, as Edler contends that its technology does, the defendant must know or have reason to know that its information is intended for the prohibited use." "These limitations are necessary both to adhere to the purpose of the Act and to avoid serious interference with the interchange of scientific and technological information." In February 1980 the U.S. Department of State wrote Munitions Control Newsletter # 80 which stated in part: "Concern has been voiced that ITAR provisions relating to the export of technical data as applied to cryptologic equipment can be so broadly interpreted as to restrict scientific exchanges of basic mathematical and engineering research data. The Office of Munitions Control wishes to clarify the application of the technical data provisions of Section 121.01, Category XVIII, of the ITAR as applied to equipment found in Categories XI(c) and XIII(b) of the Munitions List." It [Ed: OMC's interpretation of ITAR] does not include general mathematical, engineering or statistical information, not purporting to have or reasonably expected to be given direct application to equipment in such categories. It does not include basic theoretical research data. It does, however, include algorithms and other procedures purporting to have advanced cryptologic application." "The interpretation set forth in this newsletter should exclude from the licensing provisions of the ITAR most basic scientific data and other theoretical research information, except for information intended or reasonably expected to have a direct cryptologic application." The bottom line of this is that there are at least some things which are exempt from ITAR licensing. The definition of *what* those things are is still ill-defined, more than a decade later. On April 18, 1988 the Office of Munitions Control sent me the following letter: "On February 27, 1987 the Department of State ruled that your software [Ed: for which I had already received approved licenses] which performs encryption, decryption, and key generation functions is covered by the U.S. Munitions List (22 CFR 121.1). Your letter of March 4, 1987 [Ed: more than a year before they sent their response in this letter] suggests that the software in questions [sic] is in the public domain and should therefore not be subject to licensing under the International Traffic in Arms Regulations (ITAR). The Department of State has reviewed this matter further and does not concur with the contention that cryptologic software is technical data exempt from licensing requirements under 22 CFR 120.18 and 125.1(a)." "Cryptologic software is not technical data under Category XVIII of the Munitions List. Such software is specifically enumerated in Category XIII(b). Is [sic: It] is therefore ineligible for treatment as technical data by virtue of its inclusion in Category XIII(b) (see 22 CFR 121.8(f)). Accordingly, it is not subject to the provision of 22 CFR 120.18 and 125 regarding public domain and technical data licensing exemptions, respectively." [Ed: the sentence above is important -- re-read it! It says that CRYPTO SOFTWARE CAN NOT BE IN THE PUBLIC DOMAIN. And by the way, the ITAR definition of *SOFTWARE* includes ALGORITHMS, etc.] "Accordingly, export license requests must be submitted to this office for review and approval. They will be considered on a case- by-case basis." Although information had been communicated to me verbally, I had to file a Freedom of Information Act request to receive a written copy of NSA's input on this case. It was in grand total the following one sentence (marked DECLASSIFIED): "Although software was developed from open source material, the application of that information into the subject software program contains cryptographic capabilities that are controlled under category 13B." The U.S. Department of Commerce took the opposite stance: There is no military application identified. The software is also written without a military application in mind." Guess What! When NSA and Commerce hold opposite views, the Department of State breaks the tie, and SURPRISE! they say that the State Department control it [via ITAR]! If waiting more than a year to get a response seems bad, more than two years ago I sent for Commodity Jurisdiction (CJ) determination of a 4-line BASIC program which implements a Caesar Shift Cryptosystem (you know IBM <--> HAL when the shift is "1"). Such a cryptosystem is two thousand years old [see _The Codebreakers_ page 83]. It is clear that OMC and NSA has taken [and I believe they know it] an untenable position that no crypto software can be in the public domain. However they balance this untenable position by doing NOTHING! They don't respond, they don't complain, they don't prosecute, and they don't process my written CJ or DSP5 applications any more [they just "withdraw them from consideration" without telling me in writing]. Cryptologia has been publishing algorithms and software which have been distributed internationally for 15 years. Scientific American published what they stated is "a complete description of the DES that happens to be its most public appearance to date". And you think they submitted to OMC individualized DSP-5 licenses for each international subscriber they have (and then waited more than a year for a response)?! Tony Patti Editor & Publisher Cryptosystems Journal P.O. Box 188 Newtown, PA 18940-0188 Phone: (215)579-9888 From news.admin Mon Oct 28 23:52:13 1991 Xref: news-server.csri.toronto.edu news.admin:18050 sci.crypt:6499 Path: news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!cs.umn.edu!lynx!nmsu!opus!ted From: ted@nmsu.edu (Ted Dunning) Newsgroups: news.admin,sci.crypt Subject: Re: U.S. Cryptographic export restrictions Message-ID: Date: 27 Oct 91 16:06:09 GMT References: <1991Oct19.192053.17624@nntp.hut.fi> <1991Oct23.031155.29060@sq.sq.com> <9686@cactus.org> <49294@cup.portal.com> Sender: news@NMSU.Edu Reply-To: ted@nmsu.edu Followup-To: news.admin Organization: Computing Research Lab Lines: 32 In-reply-to: Tony_S_Patti@cup.portal.com's message of 27 Oct 91 03:11:59 GMT In article <49294@cup.portal.com> Tony_S_Patti@cup.portal.com writes: "Cryptologic software is not technical data under Category XVIII of the Munitions List. Such software is specifically enumerated in Category XIII(b). Is [sic: It] is therefore ineligible for treatment as technical data by virtue of its inclusion in Category XIII(b) (see 22 CFR 121.8(f)). Accordingly, it is not subject to the provision of 22 CFR 120.18 and 125 regarding public domain and technical data licensing exemptions, respectively." [Ed: the sentence above is important -- re-read it! It says that CRYPTO SOFTWARE CAN NOT BE IN THE PUBLIC DOMAIN. And by the way, the ITAR definition of *SOFTWARE* includes ALGORITHMS, etc.] i don't think so. what they are saying is that only technical data is eligible for consideration as exempt from the ITAR requirements because it is public domain. they are not saying that software cannot be public domain, only that it is controlled even if it is public domain. if you are so inclined, the following table might help describe their position: Public Domain Private Data uncontrolled controlled Software controlled controlled From news.admin Mon Oct 28 23:52:32 1991 Xref: news-server.csri.toronto.edu news.admin:18056 sci.crypt:6502 Path: news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!fernwood!portal!cup.portal.com!Tony_S_Patti From: Tony_S_Patti@cup.portal.com Newsgroups: news.admin,sci.crypt Subject: Re: U.S. Cryptographic export restrictions Message-ID: <49327@cup.portal.com> Date: 28 Oct 91 05:07:18 GMT References: <1991Oct19.192053.17624@nntp.hut.fi><1991Oct23.031155.29060@sq. sq.com> <9686@cactus.org><49294@cup.portal.com> Organization: The Portal System (TM) Lines: 111 In article 10/27/91 08:06 32/1185 ted@nmsu.edu (Ted Dunning) writes: > i don't think so. what they are saying is that only technical data is > eligible for consideration as exempt from the ITAR requirements > because it is public domain. they are not saying that software cannot > be public domain, only that it is controlled even if it is public > domain. > > if you are so inclined, the following table might help describe > their position: > > Public Domain Private > > [Technical] Data uncontrolled controlled > > Software controlled controlled Ted, you are entitled to your opinion of what YOU think THEY mean by their statement. But since I have lived through this and have had lots of written, and verbal discussions with the people who administer ITAR, I suggest that YOUR interpretation of THEIR position is wrong, not mine. The reason I HAD to apply for licenses to export free crypto software was because they took the position that CRYPTO SOFTWARE COULD NOT BE IN THE PUBLIC DOMAIN which would exempt it from ITAR. The sections they reference are: 120.18 : ITAR's definition of "Public Domain", and 125 : "Licenses for the Export of Technical Data..." As an aid to understanding what they are saying, appearing again below is their quotation: "Cryptologic software is not technical data under Category XVIII of the Munitions List. Such software is specifically enumerated in Category XIII(b). Is [sic: It] is therefore ineligible for treatment as technical data by virtue of its inclusion in Category XIII(b) (see 22 CFR 121.8(f)). Accordingly, it is not subject to the provision of 22 CFR 120.18 and 125 regarding public domain and technical data licensing exemptions, respectively." and its conversion from bureaucratic language to English: 1. Cryptologic software is not technical data RELATING to a defense article. 2. Cryptologic software IS ITSELF A DEFENSE ARTICLE (not technical data). [Part 123 of ITAR rather than PART 125 which covers technical data]. 3. The Public Domain exemption applies to technical data not defense articles, and since we (OMC) have decided that cryptologic software is NOT technical data, we conclude that therefore cryptologic software can not be in the public domain ever. In other words, if it isn't technical data it therefore also isn't public domain [for ITAR purposes]. 4. Cryptologic software is not subject to << the public domain exemption >> and << licenses for the export of technical data >> respectively. Therefore, part 123 "Licenses for the export of Defense Articles" applies instead of part 125. I SHOULD STATE AGAIN THAT I DO NOT AGREE AT ALL WITH WHAT THEY SAY. I DO NOT THINK THAT IT MAKES SENSE. I DO NOT BELIEVE THAT THEIR STATEMENTS AGREE WITH THE INTENT OF THE LAW, THE CONSTITUTION, WITH JUDICIAL DECISIONS, OR WITH THEIR OWN PRIOR STATEMENTS (specifically OMC Newsletter #80 entitled "Cryptography/Technical Data". You see, paragraph 2 of their newsletter begins "Cryptologic technical data...". It is just convenient for them that they decide later that this category does not include cryptologic software [in section 121.8(f) software includes but is not limited to the system functional design, logic flow, algorithms, application programs, operating systems and support software for design, implementation, test, operation, diagnosis and repair]. This definition itself can lead to bizarre ends: "MS-DOS and Turbo Pascal are operating system and support software used for the design and implementation of PC-based crypto software". Therefore, I would guess OMC would consider both MS-DOS and Turbo Pascal to be ITAR controlled defense articles also! Their whole position is untenable and so utterly broad (or can be so broadly interpreted) as to potentially restrict EVERYTHING. YOU WANTED TO KNOW WHAT THEY THINK ITAR IS, AND IT IS WHAT I STATE ABOVE. Ted, you think that OMC interprets ITAR to say that "cryptologic software is controlled even if it is public domain." (re-phrased from your quote above). However, I think I have shown that they expressly take the position that cryptologic software CAN NOT BE PUBLIC DOMAIN BECAUSE IT IS NOT TECHNICAL DATA (only technical data can be public domain). A more accurate table (following your inspiration) of OMC's position is: Public Domain Non-Public-Domain ------------- ----------------- Technical Data EXEMPT controlled (does not include software does not include algorithms) Software N/A controlled Hardware N/A controlled You or anyone else can play a game of semantics with OMC's words, but I KNOW WHAT THEIR POSITION WAS IN THE LETTER I QUOTED BECAUSE IT WAS SENT TO ME. I hope that OMC/NSA will eventually take a more reasonable and tenable position in the future. But until I see something on their letterhead which is different from what I stated above, I will continue to know that this is their current untenable position. Tony Patti Editor & Publisher Cryptosystems Journal P.O. Box 188 Newtown, PA 18940-0188 Phone: (215)579-9888 From news.admin Tue Oct 29 22:36:12 1991 Xref: news-server.csri.toronto.edu news.admin:18075 sci.crypt:6508 Path: news-server.csri.toronto.edu!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!transfer!lectroid!ellisun!cme From: cme@ellisun.sw.stratus.com (Carl Ellison) Newsgroups: news.admin,sci.crypt Subject: Re: U.S. Cryptographic export restrictions Message-ID: <8846@lectroid.sw.stratus.com> Date: 29 Oct 91 20:07:12 GMT References: <49327@cup.portal.com> <1991Oct29.184015.15308@sci.ccny.cuny.edu> Sender: usenet@lectroid.sw.stratus.com Followup-To: news.admin Organization: Stratus Computer, Inc. Lines: 9 In article <1991Oct29.184015.15308@sci.ccny.cuny.edu> dan@sci.ccny.cuny.edu (Dan Schlitt) writes: >I call your attention to the "born classified" doctrine that is >applied to nuclear weapons information. By the way, the Congress had hearings on this issue back in the early 80's and found no basis for an argument that cryptographic research is born classified. I know you didn't intend to imply that there was, but wanted to forestall speculation. From news.admin Fri Nov 1 14:39:07 1991 Xref: news-server.csri.toronto.edu news.admin:18094 sci.crypt:6518 Path: news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!wupost!uunet!fernwood!portal!cup.portal.com!Tony_S_Patti From: Tony_S_Patti@cup.portal.com Newsgroups: news.admin,sci.crypt Subject: Re: U.S. Cryptographic export restrictions Message-ID: <49472@cup.portal.com> Date: 31 Oct 91 01:27:58 GMT References: <49294@cup.portal.com> <49327@cup.portal.com> <1991Oct28.165353.7938@newshost.anu.edu.au> Organization: The Portal System (TM) Lines: 63 In 10/28/91 06:36 183/9105 cmf851@csc2.anu.edu.au (Albert Langer) writes: > I won't agree that this proves the Government is being stupid either > - just that they are engaging in illegal intimidation themselves, > which so far has worked. If simple letter writing does not force > them to abandon this position I hope somebody does take them to > court over it - perhaps it is time to call in ACLU and EFF? I don't consider what I did "simple letter writing". For one thing, you don't see the telephone calls and other work involved. Actually, the ACLU office in Washington, DC across the street from the U.S. Supreme Court building was involved with, received carbon copies of, and provided moral support for my endeavors. I suspect this is one of the reasons why it took OMC over a year to write a 4 paragraph letter. While I will not comment on other ACLU efforts, they are in my opinion the most effective group in "protecting the Bill of Rights" (I use, among other metrics, the number of cases taken to the U.S. Supreme Court). They certainly provided useful support of my efforts to protect the First Amendment. For further information related to this, other subjects (for example submitting FOIA Requests), or joining, their addresses are: ACLU ACLU 122 Maryland Avenue, NE 132 West 43 Street Washington, DC 20002 New York, NY 10036 I have indeed also corresponded with the Electronic Frontier Foundation (EFF) concerning this matter. In 10/28/91 08:53 100/5551 cmf851@csc2.anu.edu.au (Albert Langer) writes: > I see nothing in their letter claiming > that no cryptographic software could meet the definition of "public > domain" in section 120.18 but simply that it would not be excluded > from ITAR controls even if it was, since the exclusion of public > domain information from controls in 125.1(a) does not apply. I do not agree with your or Ted's interpretation on this point. 1. I put forth a claim to OMC that my FREE crypto software was ITAR exempt because it is in the public domain [for example, I have receipts from libraries that this software resides in -- this is the section 120.18(d) public domain exemption]. Let alone that this is FREE software, etc. 2. OMC responds that crypto software is not technical data but instead a defense article. 3. OMC achieves what they want (rejecting my public domain claim) because you can NOT have a public domain defense article (you can't have "public domain ballistic missles") -- or choose any other type of military hardware you want to use as an example. 4. "Public domain means information" (the first 4 words in the section 120.18 definition of public domain. By their definition above, OMC says crypto software is NOT information (technical data) but instead a defense article. OMC's position is that there can NOT BE PUBLIC DOMAIN CRYPTO SOFTWARE. My interpretation of OMC's position on this point is the correct one. Tony Patti Editor & Publisher Cryptosystems Journal P.O. Box 188 Newtown, PA 18940-0188 Phone: (215)579-9888 From news.admin Fri Nov 1 14:59:56 1991 Xref: news-server.csri.toronto.edu news.admin:18106 sci.crypt:6523 Path: news-server.csri.toronto.edu!utgpu!watserv1!watmath!att!linac!uwm.edu!wupost!cs.utexas.edu!swrinde!gatech!bloom-beacon!bloom-picayune.mit.edu!athena.mit.edu!olsen From: olsen@athena.mit.edu (James J Olsen) Newsgroups: news.admin,sci.crypt Subject: Re: U.S. Cryptographic export restrictions Message-ID: <1991Oct31.181844.11151@athena.mit.edu> Date: 31 Oct 91 18:18:44 GMT References: <49327@cup.portal.com> <1991Oct28.165353.7938@newshost.anu.edu.au> Sender: news@athena.mit.edu (News system) Organization: Massachusetts Institute of Technology Lines: 28 Nntp-Posting-Host: e40-008-13.mit.edu In article <1991Oct28.165353.7938@newshost.anu.edu.au> cmf851@csc2.anu.edu.au (Albert Langer) suggests that since the Office of Munitions Control (OMC) has stated that cryptographic software is a "defense article" and not "technical data", one is free to 'disclose' this software electronically: >Why argue with them? The exclusion of "public domain" information >from their controls is irrelevant unless you want to "send or take" >cryptographic software out of the United States. They have handed you >on a platter the opportunity to merely "disclose" it by "electronic >means" without needing a licence until such time as they withdraw >their claim. 22 CFR 120.10 [Export] states: "Export" means, for purposes of this subchapter: (a) Sending or taking defense articles out of the United States in any manner... It is inconceivable to me that OMC would not interpret this section to include electronic transmission of 'defense articles'. Compared to the other linguistic handstands OMC has already performed, this one is comparatively modest. N.B.: I don't *agree* with OMC on this. I think export controls on publicly-available software are neither practically, nor legally, nor constitutionally defensible. What I am saying is that their argument isn't so patently absurd as to be thrown out of court. That's all they need for now. From list-admin Fri Nov 1 21:09:53 EST 1991 Path: news-server.csri.toronto.edu!cs.toronto.edu!snmp-distribution-owner Date: Tue, 29 Oct 1991 16:43:00 -0500 From: tmendez@wellfleet.com (Trevor Mendez) Message-ID: <9110292143.AA15783@canna.wellfleet.com> Original-To: oldera@mercury.twg.com Subject: Re: MD-4 & DES Original-Cc: snmp@uu.psi.com, tmendez@wellfleet.com Newsgroups: list.snmp Distribution: list Sender: list-admin@cs.toronto.edu Approved: list.snmp@mail.cs.toronto.edu Lines: 26 Ed, I have also been interested to learn whether DES and MDx are freely exportable. > What is the status of the exportability of the DES which is >to be used for privacy in the proposed SNMP security mechanism? I discovered that exportation of DES requires an export license that is obtainable from the U.S. Dept. of Commerce on a case by case basis. A contact there is: Hans van Gelder Export Administration Office of Techonology and Policy Analysis U.S. Dept. of Commerce Washington, D.C. (202) 377-1663 MD4 similary requires a license, however, it may be possible to obtain a general license, since MD4 is used only for authentication and cannot be used to enforce confidentiality. Vint Cerf came up with the following point of contact, for this issue: Mr. Joe Westlake, 202-377-0731. Trevor