Subject: RISKS DIGEST 13.22 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 3 March 1992 Volume 13 : Issue 22 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: RISKS in Test Standards -- A 900,000-mile Oldsmobile? (Andrew C. Green) ATMs gobble bankcards in Colorado (Rex E. Gantenbein) Re: Virus news-bite omits crucial information (Vesselin Bontchev) Re: Not quite anonymous FTP (Jonathan I. Kamens) FLIGHT INTERNATIONAL on A320's VOR... (Robert Dorsett) RSA Laboratories announces RSAREF free cryptographic toolkit (Burt Kaliski) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP domain folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 13, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Tue, 03 Mar 1992 08:34:59 CST From: acg@hermes.dlogics.com Subject: RISKS in Test Standards -- A 900,000-mile Oldsmobile? Here in northern Illinois, we must have our cars tested periodically (usually once a year) for exhaust emissions. The test operator has to enter the current mileage of the vehicle into the computer, which then sets the proper standards that the vehicle must meet. High-mileage cars are permitted to spew out slightly more pollutants (within reason) than low-mileage ones. Up until this year, the operator could only enter five digits, so any car exceeding 100,000 miles on the odometer was listed at 99,000. This year, they've revised the system to handle six digits, and things got interesting. Last week I brought my 90,000-mile 1982 Oldsmobile in for its test. The test operator said, "What's the first two digits on your mileage?" "Nine, Zero", I replied. He punched it in and the test proceeded. I wondered at the time how they deal with cars having SEVEN digit odometers. Seems like the operator would have to know whether to punch in a leading zero, but from the wording of the question, it sounded like he could only enter two digits no matter what. The owner of a 90,000-mile Honda (whose odometer reads "090,000.0") might have answered "Zero, Nine" to that question, and get stuck trying to meet a 9,000-mile emission standard instead of a 90,000-mile setting. On the other hand, maybe I would be the lucky recipient of a 900,000-mile testing standard? If my car fails THAT, I thought, I'm definitely getting a tuneup. Well, the car passed with flying colors, and as I drove off, I glanced at the printout of results given to me with my new 1-year emissions sticker. Sure enough, the indicated test mileage read "900,000", complete with the comma in the middle. Other than the obvious RISK, that of flunking the test because of a goofed-up mileage entry, I wonder if the odometer reading for emissions testing is tracked from year to year. Data on the printout shows that the computer is indeed tied into the registration information for the car. The mileage IS listed on the car's Title of Ownership to catch rollbacks between purchase and later sale, but I don't know if any discrepancies are flagged automatically. Hope not, anyway. I wonder if the operator who gets the test mileage correct next year, say at 99,000 miles, will get a message from the computer asking what happened to the other 801,000? Andrew C. Green, Datalogics, Inc., 441 W. Huron, Chicago, IL 60610 (312) 266-4431 Internet: acg@dlogics.com UUCP: ..!uunet!dlogics!acg ------------------------------ Date: Mon, 2 Mar 1992 16:20 MST From: "Rex E. Gantenbein 307-766-4226" Subject: ATMs gobble bankcards in Colorado Source: Denver Post, 19 Feb 1992 About 1,000 Colorado ATM users had their Visas and Mastercards abruptly terminated in February by an out-of-control computer system. For 90 minutes during the President's Day weekend, the Rocky Mountain Bankcard System software told ATMS around the state to eat the cards instead of dishing out cash or taking deposits. The "once-in-a-decade" glitch went unnoticed because it occurred as programmers were patching in a correction to a different problem. The company is rushing new plastic and letters of apology to customers who got terminated. ------------------------------ Date: Tue, 3 Mar 92 10:30:29 +0100 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) From: news@rzsun2.informatik.uni-hamburg.de (Mr. News) Subject: Re: Virus news-bite omits crucial information risks@csl.sri.com writes: > AT NO TIME DURING THE PIECE DID ANYONE MENTION THAT THE VIRUS > AFFECTS MS-DOS CLONE MACHINES ONLY. Sigh... Sorry, but this is FALSE! The Michelangelo virus attacks any IBM PC compatible computers. There is no need that they are MS-DOS machines. You can get a 80386 and install only Xenix on it, without any MS-DOS partitions. The virus will still infect it and will destroy the information on the hard disk on March 6. Of course, Xenix won't be able to boot after the infection, but this is another story... Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Tue, 3 Mar 92 10:21:19 -0500 From: "Jonathan I. Kamens" Subject: Re: Not quite anonymous FTP (Rucklidge, RISKS-13.21) The risk is not so much that the logs are made, but more that the service is presented as "anonymous", leading people to believe that it actually is. Not convinced. It is standard operating procedure to ask users of anonymous ftp to specify their E-mail address when prompted for a password. In fact, pretty much every document I've seen that describes anonymous ftp mentions this practice, and explains that the purpose of it is to allow system administrators to monitor the usage of anonymous ftp. Given such a widespread, accepted convention, it seems clear to me that users of anonymous ftp have no reason to expect their usage to be completely anonymous. Furthermore, if the provide a fake or bogus E-mail address when prompted for an ftp password, they are doing something considered anti-social on the Internet, and I think it is completely reasonable for the addresses of connecting sites to be logged in case it becomes necessary to follow up on such anti-social behavior. I don't see any risk here. I see a system that worked the way it was designed to work, and the users who were caught allegedly doing something wrong had no "right" to expect otherwise. Jonathan Kamens jik@MIT.Edu ------------------------------ Date: Mon, 2 Mar 92 15:32:34 CST From: rdd@cactus.org (Robert Dorsett) Subject: FLIGHT INTERNATIONAL on A320's VOR... Since the Air Inter A320 crashed January 20, there have been a number of comments on shifted map displays, and that Lufthansa had banned the use of VOR/DME approaches for the previous year. Obligatory technolingo: A VOR is a ground-based electronic broadcasting station, which transmits radial "spokes." These range from 0 to 359 degrees. An airplane can check to see which "spoke" it's on; this data can then be used for navigation purposes. This is contrasted with an NDB (non-directional station), which, like an AM radio station, simply broadcasts in all directions; direction- finding equipment on board the airplane can then be used to find it. VOR's are generally more reliable over longer ranges, and less susceptible to interference. The operational difference is that airplane instrumentation points TO an NTB, but shows what radial the airplane is ON with a VOR. Comments in brackets []. Some are sarcastic, some are technical clar- ifications; there are a few mistakes in this. >From FLIGHT INTERNATIONAL, "New VOR antenna will solve A320 problem", Feb. 19, 1992, p. 10: "Airbus Industrie, workin with Lufthansa, has developed a new VOR (VHF omnirange) antenna for its A320s. "The resulting modification programme will overcome the occasional poor air- craft reception of VOR beacon signals, which had caused Lufthansa, in Sept- ember 1991, to suspend VOR/DME (distance measuring equipment) airfield ap- proaches in its A320s. "On 8 February Air France and Air Inter took a voluntary decision to suspend VOR/DME approaches in their A320s because of an incident in an Air Inter A320 on approach to Bordeaux airport three days earlier. "The symptom for the Lufthansa problem was oscillation of the VOR indicator in the A320 cockpit displays. Also, the Bendix DME equipment in Boeing 747- 400s--the same as in the A320s--had once shown a fault which had been re- produced on the test bench. "Work at Bendix has not yet produced a modificaiton, but the fault has not recurred in the 747 or occurred ever in Lufthansa's A320s. Air France uses Bendix VOR/DME, Air Inter has Collins. "Airbus senior vice-president of engineering, Bernard Ziegler, says that the antenna problem was related to the position of metal lightning-protection strips in the composite aerial. "In the Air Inter incident on 5 February, the A320 captain, carrying out a VOR/ DME procedure for Bordeaux, but flying manually in perfect visual conditions, noticed that the flight management system (FMS)-produced map on his navigation display was displaced. Ziegler confirms it was displaced by 2.2 cm (1.2 nm), pointing out that such a degree of displacement, while unsatisfactory, was within the published system accuracy. [!!!] [!] "Lufthansa emphasizes that it had not experienced map displacement, only VOR indicator oscillation. "Lufthansa's letdown procedure involves one pilot flying to the compass arc/ map display, the other to the VOR compass rose display, to enable cross-check- ing. The raw VOR/DME data on both displays is correct even if the map is displaced. [but does anyone use the raw data when the map is so much more convenient?] "Ziegler says the Bordeaux map display displacement was caused partly by an Air Inter database error entered in the aircraft's FMS, which produces the display map from its integral inertial navigation system (INS) [actually, ADIRS]. The INS [FMS] depends on VOR/DME for its accuracy updating. If fewer than two DMEs are in range (and during descent this often occurs), then the INS [FMS] updates using a co-located VOR/DME. The Air Inter database says the Bordeaux VOR and DME are co-located when they are not [!], so the FMS was cleared to updated, using incorrect information and affecting the map. [GIGO rules!] "The navigation display, Ziegler says, displays the FMS update sources at all times: 'If you see that the source is VOR/DME and your VOR needle is oscil- lating, obviously you know you can expect map shift.' [obviously.] "The French Direction Generale de l'Aviation Civile (DGAC) will not ban A320 VOR/DME letdowns, but empahsises the need to crosscheck the map displays with the raw navigation data available. "The DGAC also points out that there is no evidence of any connection between the Bordeaux event and the Air Inter A320 crash near Starsbourg on 20 January. The authority has, however, warned all A320 crews to be careful when they sel- ect the autopilot descent mode, because there is a possibility that the Strasbourg crew may have selected a steep 3300 fpm (16.7 m/s) rate of descent when they meant to select the shallower 3.3 degree angle of descent. Robert Dorsett Internet: rdd@cactus.org UUCP: ...cs.utexas.edu!cactus.org!rdd ------------------------------ Date: Mon, 2 Mar 92 16:27:21 PST From: burt@RSA.COM (Burt Kaliski) Subject: RSA Laboratories announces RSAREF free cryptographic toolkit RSAREF(TM): A Cryptographic Toolkit for Privacy-Enhanced Mail RSA Laboratories (A division of RSA Data Security, Inc.) March 2, 1992 This document copyright (C) 1992 RSA Laboratories, a division of RSA Data Security, Inc. License is granted to reproduce, copy, post, or distribute in any manner, provided this document is kept intact and no modifications, deletions, or additions are made. WHAT IS IT? RSAREF is a cryptographic toolkit designed to facilitate rapid deployment of Internet Privacy-Enhanced Mail (PEM) implementations. RSAREF represents the fruits of RSA Data Security's commitment to the U.S. Department of Defense's Advanced Research Projects Agency (DARPA) to provide free cryptographic source code in support of a PEM standard. RSA Laboratories offers RSAREF in expectation of PEM's forthcoming publication as an Internet standard. Part of RSA's commitment to DARPA was to authorize Trusted Information Systems of Glenwood, MD, to distribute a full PEM implementation based on RSAREF. That implementation will be available this spring. RSAREF supports the following PEM-specified algorithms: o RSA encryption and key generation, as defined by RSA Laboratories' Public-Key Cryptography Standards (PKCS) o MD2 and MD5 message digests o DES (Data Encryption Standard) in cipher-block chaining mode RSAREF is written in the C programming language as a library that can be called from an application program. A simple PEM implementation can be built directly on top of RSAREF, together with message parsing and formatting routines and certificate-management routines. RSAREF is distributed with a demonstration program that shows how one might build such an implementation. The name "RSAREF" means "RSA reference." RSA Laboratories intends RSAREF to serve as a portable, educational, reference implementation of cryptography. WHAT YOU CAN (AND CANNOT) DO WITH RSAREF The license at the end of this note gives legal terms and conditions. Here's the layman's interpretation, for information only and with no legal weight: 1. You can use RSAREF in personal, noncommercial applications, as long as you follow the interface described in the RSAREF documentation. You can't use RSAREF in any commercial (moneymaking) manner of any type, nor can you use it to provide services of any kind to any other party. For information on commercial licenses of RSAREF-compatible products, please contact RSA Data Security. 2. You can distribute programs that interface to RSAREF, but you can't distribute RSAREF itself. Everyone must obtain his or her own copy of RSAREF. (However, free licenses to redistribute RSAREF are available. For information, please send electronic mail to .) 3. You can modify RSAREF as required to port it to other operating systems and compilers, as long as you give a copy of the results to RSA Laboratories. You can't otherwise change RSAREF. 4. You can't send RSAREF outside the United States, or give it to anyone who is not a United States citizen and doesn't have a "green card." (These are U.S. State and Commerce Department requirements, because RSA and DES are export-controlled technologies.) The restrictions on the distribution of RSAREF are the consequence of export-control law. Similar constraints are placed on those redistributing RSAREF under free license from RSA Laboratories. Without the export-control law, RSAREF would be available by anonymous FTP. HOW TO GET IT To obtain RSAREF, read the license at the end of the note and return a copy of the "acknowledgement and acceptance" paragraph by electronic mail to . RSAREF is distributed by electronic mail in a UNIX(TM) "uuencoded" TAR format. When you receive it, store the contents of the message in a file, and run your operating system's "uudecode" and TAR programs. For example, suppose you store the contents of your message in the file 'contents'. You would run the commands: uudecode contents # produces rsaref.tar tar xvf rsaref.tar RSAREF includes about 60 files organized into the following subdirectories: doc documentation on RSAREF and RDEMO install makefiles for various operating systems rdemo RDEMO demonstration program source RSAREF source code and include files test test scripts for RDEMO USERS' GROUP RSA Laboratories maintains the electronic-mail users' group for discussion of RSAREF applications, bug fixes, etc. To join the user's group, send electronic mail to . REGISTRATION RSAREF users who register with RSA Laboratories are entitled to free RSAREF upgrades and bug fixes as soon as they become available and a 50% discount on selected RSA Data Security products. To register, send your name, address, and telephone number to . INNOVATION PRIZES RSA Laboratories will award cash prizes for the best applications built on RSAREF. If you'd like to submit an application, or want to be on the review panel, please send electronic mail to . PUBLIC-KEY CERTIFICATION RSA Data Security offers public-key certification services conforming to forthcoming PEM standards. For more information, please send electronic mail to . OTHER QUESTIONS If you have questions on RSAREF software, licenses, export restrictions, or other RSA Laboratories offerings, send electronic mail to . AUTHORS RSAREF was written by the staff of RSA Laboratories with assistance from RSA Data Security's software engineers. The DES code is based on an implementation that Justin Reyneri did at Stanford University. Jim Hwang of Stanford wrote parts of the arithmetic code under contract to RSA Laboratories. ABOUT RSA LABORATORIES RSA Laboratories is the research and development division of RSA Data Security, Inc., the company founded by the inventors of the RSA public-key cryptosystem. RSA Laboratories reviews, designs and implements secure and efficient cryptosystems of all kinds. Its clients include government agencies, telecommunications companies, computer manufacturers, software developers, cable TV broadcasters, interactive video manufacturers, and satellite broadcast companies, among others. RSA Laboratories draws upon the talents of the following people: Len Adleman, distinguished associate - Ph.D., University of California, Berkeley; Henry Salvatori professor of computer science at University of Southern California; co-inventor of RSA public-key cryptosystem; co-founder of RSA Data Security, Inc. Taher Elgamal, senior associate - Ph.D., Stanford University; director of engineering at RSA Data Security, Inc.; inventor of Elgamal public-key cryptosystem based on discrete logarithms Marty Hellman, distinguished associate - Ph.D., Stanford University; professor of electrical engineering at Stanford University; co-inventor of public-key cryptography, exponential key exchange; IEEE fellow; IEEE Centennial Medal recipient Burt Kaliski, chief scientist - Ph.D., MIT; former visiting assistant professor at Rochester Institute of Technology; author, Public-Key Cryptography Standards; general chair, CRYPTO '91 Cetin Koc, associate - Ph.D., University of California, Santa Barbara; assistant professor at University of Houston Ron Rivest, distinguished associate - Ph.D., Stanford University; professor of computer science, MIT; co-inventor, RSA public-key cryptosystem; co-founder, RSA Data Security, Inc.; member, National Academy of Engineering; director, International Association for Cryptologic Research; program co-chair, ASIACRYPT '91 ADDRESSES RSA Laboratories RSA Data Security, Inc. 10 Twin Dolphin Drive 100 Marine Parkway Redwood City, CA 94065 Redwood City, CA 94065 USA USA (415) 595-7703 (415) 595-8782 (415) 595-4126 (fax) (415) 595-1873 (fax) PKCS, RSAREF and RSA Laboratories are trademarks of RSA Data Security, Inc. All other company names and trademarks are not. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - RSA LABORATORIES PROGRAM LICENSE AGREEMENT RSA LABORATORIES, A DIVISION OF RSA DATA SECURITY, INC. ("RSA"), IS WILLING TO LICENSE THE "RSAREF" PROGRAM FOR YOUR USE ONLY ON THE TERMS AND CONDITIONS SET FORTH BELOW. YOUR ACKNOWLEDGEMENT AND ACCEPTANCE OF THESE TERMS AND CONDITIONS BY RETURN ELECTRONIC TRANSMISSION IS REQUIRED PRIOR TO DELIVERY TO YOU OF THE RSAREF PROGRAM. 1. LICENSE. RSA is willing to grant you a non-exclusive, non-transferable license for the "RSAREF" program (the "Program") and its associated documentation, subject to all of the following terms and conditions, but only: a. to use the Program on any computer in your possession, but on no more than one computer at any time; b. to make one copy of the Program for back-up purposes only; c. to incorporate the Program into other computer programs only through interfaces described in the RSAREF Library Reference (the file "rsaref.txt" which accompanies the Program) (any such incorporated portion of the Program to continue to be subject to the terms and conditions of this license) both solely for your own personal or internal use or to create Application Programs; and d. to modify the Program for the purpose of porting the Program to any other operating systems and compilers, but only on the conditions that: (i) you do not alter any Program interface, except with the prior written consent of RSA; and (ii) you provide RSA with a copy of the ported version of the Program by electronic mail. "Application Programs" are programs which interface with the Program but which do not incorporate all or any portion of the Program, whether in source code or object code form. 2. LIMITATIONS ON LICENSE. a. RSA owns the Program and its associated documentation and all copyrights therein. YOU MAY NOT USE, COPY, MODIFY OR TRANSFER THE PROGRAM, IN EITHER SOURCE CODE OR OBJECT CODE FORM, ITS ASSOCIATED DOCUMENTATION, OR ANY COPY, MODIFICATION OR MERGED PORTION THEREOF, IN WHOLE OR IN PART, EXCEPT AS EXPRESSLY PROVIDED IN THIS AGREEMENT OR WITH THE PRIOR WRITTEN CONSENT OF RSA. WITHOUT LIMITING THE GENERALITY OF THE FOREGOING, YOU MAY NOT PLACE THE PROGRAM ON ANY ELECTRONIC BULLETIN BOARD SYSTEM (BBS) OR MAKE THE PROGRAM AVAILABLE THROUGH ANY FILE TRANSFER PROTOCOL (FTP). YOU MUST REPRODUCE AND INCLUDE RSA'S COPYRIGHT NOTICES ON ANY COPY OR MODIFICATION, OR ANY PORTION THEREOF, OF THE PROGRAM AND ITS ASSOCIATED DOCUMENTATION. b. The Program is to be used only in connection with a single computer. You may physically transfer the Program from one computer to another, provided that the Program is used in connection with only one computer at any given time. You may not transfer the program electronically from one computer to another over a network except in connection with your own personal or internal use of the Program. You may not distribute copies of the Program or its associated documentation. IF YOU TRANSFER POSSESSION OF ANY COPY, MODIFICATION OR MERGED PORTION OF THE PROGRAM, WHETHER IN SOURCE CODE OR OBJECT CODE FORM, OR ITS ASSOCIATED DOCUMENTATION TO ANOTHER PARTY, EXCEPT AS EXPRESSLY PROVIDED FOR IN THIS LICENSE, YOUR LICENSE SHALL BE AUTOMATICALLY TERMINATED. c. The Program is to be used only for non-commercial purposes. You may not use the Program to provide services to others for which you are compensated in any manner. You may not license, distribute or otherwise transfer the Program or any part thereof in any form, whether you receive compensation or not. d. You may not translate the Program into any other computer language. e. You may not incorporate the Program into other programs through interfaces other than the interfaces described in the RSAREF Library Reference. 3. NO WARRANTY OF PERFORMANCE. THE PROGRAM AND ITS ASSOCIATED DOCUMENTATION ARE LICENSED "AS IS" WITHOUT WARRANTY AS TO THEIR PERFORMANCE, MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE RESULTS AND PERFORMANCE OF THE PROGRAM IS ASSUMED BY YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU (AND NOT RSA OR ITS DISTRIBUTOR) ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 4. LIMITATION OF LIABILITY. EXCEPT AS EXPRESSLY PROVIDED FOR IN SECTION 5 HEREINUNDER, NEITHER RSA NOR ANY OTHER PERSON WHO HAS BEEN INVOLVED IN THE CREATION, PRODUCTION, OR DELIVERY OF THE PROGRAM SHALL BE LIABLE TO YOU OR TO ANY OTHER PERSON FOR ANY DIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, INCLUDING BUT NOT LIMITED TO ANY DAMAGES FOR LOST DATA, RE-RUN TIME, INACCURATE INPUT, WORK DELAYS OR LOST PROFITS, RESULTING FROM THE USE OF THE PROGRAM OR ITS ASSOCIATED DOCUMENTATION, EVEN IF RSA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 5. PATENT INFRINGEMENT INDEMNITY. RSA shall indemnify and hold you harmless from any and all liability, damages, costs or expenses (including reasonable attorneys' fees) which you may incur as the result of any claim that the unmodified Program infringes a United States patent in the field of cryptography. RSA shall have no obligation to you pursuant to this Section 5 unless: (i) you give RSA prompt written notice of the claim; (ii) RSA is given the right to control and direct the investigation, preparation, defense and settlement of the claim; and (iii) the claim is based on your use of the unmodified Program in accordance with this license. THIS SECTION 5 SETS FORTH RSA'S ENTIRE OBLIGATION AND YOUR EXCLUSIVE REMEDIES CONCERNING CLAIMS FOR PROPRIETARY RIGHTS INFRINGEMENT. NOTE: PORTIONS OF THE PROGRAM PRACTICE METHODS DESCRIBED IN AND ARE SUBJECT TO U.S. PATENTS #4,218,582 AND #4,405,829, ISSUED TO LELAND STANFORD JR. UNIVERSITY AND MASSACHUSETTS INSTITUTE OF TECHNOLOGY RESPECTIVELY. EXCLUSIVE LICENSING RIGHTS ARE HELD BY PUBLIC KEY PARTNERS OF SUNNYVALE, CALIFORNIA. 6. RESTRICTIONS ON FOREIGN RESHIPMENT. THIS LICENSE IS EXPRESSLY MADE SUBJECT TO ANY LAWS, REGULATIONS, ORDERS, OR OTHER RESTRICTIONS ON THE EXPORT FROM THE UNITED STATES OF AMERICA OF THE PROGRAM OR OF ANY INFORMATION ABOUT THE PROGRAM WHICH MAY BE IMPOSED FROM TIME TO TIME BY THE GOVERNMENT OF THE UNITED STATES OF AMERICA. YOU MAY NOT EXPORT OR REEXPORT, DIRECTLY OR INDIRECTLY, THE PROGRAM OR INFORMATION PERTAINING THERETO. 7. TERM. The license granted hereunder is effective until terminated. You may terminate it at any time by destroying the Program and its associated documentation together with all copies, modifications and merged portions thereof in any form. It will also terminate upon the conditions set forth elsewhere in this Agreement or if you fail to comply with any term or condition of this Agreement. You agree upon such termination to destroy the Program and its associated documentation, together with all copies, modifications and merged portions thereof in any form. 8. GENERAL a. You may not sublicense the Program or its associated documentation or assign or transfer this license. Any attempt to sublicense, assign or transfer any of the rights, duties or obligations hereunder shall be void. b. This agreement shall be governed by the laws of the State of California. c. Address all correspondence regarding this license to RSA's electronic mail address , or to RSA Laboratories ATTN: RSAREF Administrator 10 Twin Dolphin Drive Redwood City, CA 94065 USA d. TO RECEIVE THE PROGRAM AND ITS ASSOCIATED DOCUMENTATION BY ELECTRONIC TRANSMISSION, YOU MUST TRANSMIT THE FOLLOWING ACCEPTANCE AND ACKNOWLEDGMENT TO RSA'S ELECTRONIC MAIL ADDRESS : ACKNOWLEDGMENT AND ACCEPTANCE I acknowledge that I have read the RSAREF Program License Agreement and understand and agree to be bound by its terms and conditions, including without limitation its restrictions on foreign reshipment of the Program and information related to the Program. The electronic mail address to which I am requesting that the program be transmitted is located in the United States of America and I am a United States citizen or a permanent resident of the United States. The RSAREF License Agreement is the complete and exclusive agreement between RSA Laboratories and me relating to the Program, and supersedes any proposal or prior agreement, oral or written, and any other communications between RSA Laboratories and me relating to the Program. ------------------------------ End of RISKS-FORUM Digest 13.22 ************************