NASA National Aeronautics and Space Administration Washington D.C. 20546 JTD James H. Burrows, Director Computer Systems Laboratory Technology Building, Room B154 National Institute of Standards and Technology Gaithersburg, Maryland 20899 Dear Mr. Burrows: NASA has reviewed the proposed Federal Information Processing Standard (FIPS) for and Escrowed Encryption Standard (EES) and provides comments below. NASA does not support the adoption of the proposed FIPS for and EES. NASA understands the need to keep sensitive, unclassified information from those without a need to know, however the EES is not appropriate for use in the NASA environment. Many NASA organizations are currently utilizing Data Encryption Standard (DES) based devices for the telecommunication of sensitive unclassified data. NASA has identified several EES-related issues that need to be addressed. The significant issues are discussed below. 1. Devices using the EES (CAPSTONE and CLIPPER), which implement the classified SKIPJACK algorithm, must be programmed. The chip programmer is a device provided by the National Security Agency (NSA). There is no assurance, without scrutiny, that all keying material introduced during the chip programming is not already available to the NSA. Thus, not only do the key escrow agents have a decryption capability,the NSA also retains this capability. As long as the programming devices are controlled by the NSA, there is no way to prevent the NSA from routinely monitoring all SKIPJACK encrypted traffic. Moreover, compromise of the NSA keys, such as in the Walker case, could compromise the entire EES system. 2. Users with criminal intent who are smart enough to use encryption will employ their own algorithms, thereby defeating EES devices. Should EES devices be mandated under law, these users will still encrypt the information feeding into the EES devices, thereby defeating EES. 3. Commercial and international use issues must be resolved in order for there to be value to the government. If the EES is not adopted by non-government organizations, Federal agencies will be impacted by a significant cost and inefficiency factors. This is particularly true of government agencies with many non-government customers and suppliers. 4. Implementation of this standard would result in a significant, adverse impact to NASA. The Headquarters Computer Network, other local area networks, and many computers that are not TEMPEST-rated would have to be modified or replaced at considerable cost. NASA would no be able to use the Internet or any other network that did not use the same encryption method and the same encryption key. EES devices offer no significant benefit to NASA over existing DES-base devices and their implementation would adversely impact many NASA organizations. Therefore, NASA does not concur with the adoption of the proposed FIPS for an EES. Benita A. Cooper Associate Administrator for Management Systems and Facilities
UNITED STATES DEPARTMENT OF COMMERCE OFFICE OF THE SECRETARY WASHINGTON, D.C. 20230 MAY 23, 1997 Mr. Charles R. Smith Softwar 7707 Whirlaway Drive Midlothian, Virginia 23112 Dear Mr. Smith: This is an interim response to your Freedom of Information Act (FOIA) request dated April 5, 1997 requesting 1) All data provided to and/or about the following individuals in reference with project Clipper, encryption software, legislation on encryption software, policy and contractual arrangements. Specifically, Clipper algorithm information provided, policy and/or briefing papers in connection with encryption software: Vice President Gore, Mrs. Hillary Clinton, Ginger Lew, Ira Sockowitz, James Bidzos, CEO of RSA Inc, and George Tenet and 2) Information on financial donations, meetings, negotiations, and policy decisions in reference to Government negotiations to purchase or obtain controlling interest in RSA Inc., an encryption software company owned by James Bidzos. We are enclosing responsive documents to your request which are either not subject to exemption from release under the FOIA or for which the Department has made a discretionary disclosure. Seven documents which provide legal advice concerning project Clipper are being withheld under attorney-client privilege incorporated into exemptions (b)(5), two documents are being withheld under the attorney-client privilege and deliberative process privilege incorporated into exemption (b)(5) and one document is being withheld under the deliberative process privilege incorporated into exemptions (b)(5). Three documents are being withheld in part under the attorney-client and attorney work-product privileges incorporated into exemption (b)(5). We have located five documents that originated at agencies other than the Department of Commerce. Pursuant to Department of Commerce regulations (15 CFR 4.6 (1)(4)), we have referred one document to the United States Department of Justice. You may contact Patricia D. Harris, FOIA Officer, Department of Justice, FOIA/PA Section, Room B-208 Justice Management Division, Washington, D.C. 20530 regarding the status of their review of this document. We have also referred four documents to another agency for consultation. We will inform you of our decision with respect to these documents after we receive the results of the agency review. In addition, you should be aware that several documents which are being released to you were created by entities outside of the Government and are copyrighted. We have not completed our review of all the records which are responsive to your request. We will be providing you with a final response once our review of those additional records have been completed. You have a right to appeal this partial denial of your request within 30 days of the date of this letter. Any appeal should be addressed to the Assistant General Counsel for Administration, Room 5898-C, U.S. Department of Commerce, 14th and Constitution Avenue, N.W., Washington, D.C. 20230. Any appeal should include a copy of the original request, this response, and a statement of the reasons why this response is in error. Both the appeal letter and the envelope should be clearly marked "Freedom of Information Act Appeal." Sincerely, Bettie Baca Executive Secretary Enclosures cc: Patricia D. Harris
Redacted material consists of FAX cover page (all of page 1), hand written notes placed on the right hand side of page 3, and a "sticky" note with handwritten comments placed on the lower left hand side of the same memo on page 7. Page 8 was the same memo without the note.>
AREAS MARKED "XXXX" ARE REDACTED.
10/01/93 10:57 301 948 1784 NIST CSL 002 TRUSTED INFORMATION SYSTEMS, INC. Computer and Communications Security STEPHEN T. WALKER PRESIDENT GLENWOOD, MD LOS ANGELES, CA MINNEAPOLIS, MN MT. VIEW, CA LONDON, UK September 28, 1993 Director, Computer Systems Laboratory National Institute of Standards and Technology Technology Building, Room B-154 Gaithersburg, MD 20899 Attn: Proposed FIPS for Escrowed Encryption Standard Dear Sir: On behalf of TIS, I hereby submit our very serious objections to the referenced proposed Federal Information Processing Standard (FIPS) and our recommendation that this proposal be rejected by the Department of Commerce for consideration as a FIPS. Our objections are in three all encompassing areas. First, this draft is a corruption of the basic FIPS process itself. Second, it is a technically content-free standard. Third, it lacks any evidence of an economic analysis of the cost-benefit relationship of the proposed key escrow process. 1. Corruption of the FIPS Process This proposed FIPS deviates so significantly from the "normal" FIPS process that it violates almost thirty years of tradition of open standards that have been subjected to repeated public scrutiny and arc as technically sound as any public process can make them. Independent of the contents of this proposed FIPS, this shift in the FIPS process itself must be resisted if we are ever to have technical standards that are acceptable to the public again. The traditional FIPS process, as represented by the very recent FIPS 140-1 proposal, typically involves the generation of a set of technical ideas which are discussed in public workshops and seminars, followed by a draft proposed standard which is widely distributed for public comment, often followed by several iterations, each attempting to meet the technical concerns of particular segments of the public and, eventually, resulting in a FIPS document that represents an acceptable compromise of technical ideas. This process, amazingly similar to the way Congress passes legislation, however long and frustrating, is undoubtedly the best process we will ever devise for producing a publicly acceptable standard that will be implemented by industry and yield products that can be purchased by consumers as well as the Government. The Escrowed Encryption Standard (EES) proposed FIPS completely ignores this process and puts forth in the briefest, technically content-free document possible, a proposal which forces the public to rely completely on secret information that they will never be able to examine or understand. Secret specifications may be a necessary part of developing equipment and 3060 WASHINGTON ROAD (RT. 97) GLENWOOD, ND 21738 (301) 854-6889 (301) 854-5363 (FAX) 10/01/93 10:57 301 948 1784 NIST CSL 003 Director, Computer Systems Laboratory September 28, 1993 Page 2 procedures for protecting classified national security related information. But, they have no place in a free society in protesting unclassified Government and commercial information. One must assume that the technicians that have devised the classified background for this FIPS shell are good at what they are doing (though the rumored further delay in availability of Clipper chips to the first quarter of 1994 does not build one's confidence). But, one must question the need for such secrecy and the price the Government will pay for being unwilling to share the technology by which it intends to protect our unclassified information. There are alternatives to key escrow encryption that are technically sound and could follow the traditional FIPS approach. There are multiple instances of telephone security devices that are presently commercially available using proprietary approaches that could last to the Date Encryption Standard, by which NIST seeks proposals from industry and negotiates to have complete rights granted to the public to use the approved commercial approach. For unspecified reasons, NIST has chosen to abdicate its FIPS procedures and, without seeking public suggestion, to proceed directly with this unorthodox classified FIPS approach. The only apparent reason given for the haste with which this process is proceeding is that "the President said he wanted it." Apparently, the staff people who prepared the President's statement of April 16, 1993 on the Clipper Initiative included comments to the effect that NIST should proceed quickly to develop a FIPS covering key escrow procedures. I do not believe that if President Clinton understood, when he XXXXXX signed the April 16 announcement, he was asking for such a XXXXXX corruption of the technical process by which FIPS are developed, XXXXX he would have signed the announcement. XXXXX XXXXX 2. Technically Content-Free Standard XXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXX This proposed standard contains so little specific information XXXXXX that it is almost totally useless to anyone attempting to XXXXXXX implement a key escrow telephone system. The single most XXXXXXX important motive for a FIPS is to establish a means for XXXXXXX interoperability among multiple vendors' products. If there is XXXXX so little information available in the FIPS that no one knows XXXXXXX how to implement it without a classified contract, then I XXXXXXX believe this document should not be called a FIPS. XXXXXXX XXXXXXXXXX It relies upon specifications of the encryption/decryption XXXXXXX algorithm (SKIPJACK) and the LEAF Creation Method 1 (LCM-1) XXXXXXX that are classified. XXXXXXX XXXXXXX There is precedent in a very brief FIPS (FIPS_107 on Local Area XXXXXX Networks), but, in this case, the FIPS references a publicly XXXXXX available, extensively reviewed and unclassified XXXXXXX XXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXX 10/01/93 10:58 301 948 1784 NIST CSL 004 Director, Computer Systems Laboratory September 28, 1993 Page 3 American National/IEEE/ISO Standard (802.3) that gives complete specifications for implementing that standard. Anything less than this should be unacceptable as a FIPS. 3. Lack of a Cost-Benefit The entire key escrow process, as it has been reported in public over the past six months, seem s to be devoid of any analysis of what it will cost verses what it will accomplish. Perhaps the Government has performed such an analysis, but I am unaware of any indications to that effect. In the same spirit that I offered my comments on the fundamental flaws in the NIST proposal to license the Digital Signature Algorithm to the Public Key Partners Corporation, I now offer the following relatively superficial analysis of the law enforcement benefits of key escrow. I hope this simple look will be augmented by better information from the Administration that will show that I am wrong in my approach and/or conclusions. If one estimates the number of telephone security devices that may be in use in the U.S. in the next ten years, one must acknowledge that, for the most part, the general public will not spend the extra money to protect its routine phone calls from an unforeseen threat. Business will probably purchase these devices for their executives but not bother for the bulk of their routine transactions. As a result, I estimate that, optimistically, as many as ten percent (10%) of the public phones in the U.S. may be protected with security devices in the next ten years. Given that the Administration has assured us that the public will not be prohibited from using alternative encryption systems, when one considers how many of these devices will be key escrow devices, one must take into account already available competing devices such as the AT&T proprietary 3600s and the Cylink DES devices which do not use key escrow procedures. I estimate that of the installed devices, no more than fifty percent (50%) will be key escrowed devices in the next ten years. The number of Title III wiretaps that take place in a given year is approximately 4,000 ( the number of court ordered wiretaps is approximately 800 times an average of 5 physical taps per court order). If my estimate of the number of key escrow phone devices is accurate and those estimates represent the population of phones that the law enforcement authorities expect to encounter when placing a wiretap, then we should see approximately 200 actual key escrowed phone taps in any given year or approximately 16 per month; 1 every 2 days or so. This is hardly enough to justify all the key escrow administrative expenses. Unfortunately, the estimates of five percent (5%) of the U.S. phones having and using key escrow devices is not likely to be representative of the population of phones that law enforcement authorities will encounter. Business executives will use key escrow phones, but 10/01/93 10:58 301 9481784 NIST CSL Director, Computer Systems Laboratory September 28, 1993 Page 4 those that do not want their calls monitored by anyone will chose devices that are not subject to key escrow. So even the optimistic numbers cited above are probably overly optimistic. One cannot avoid commenting that it appears the key escrow agents will no doubt make the Maytag repair man look like a beehive of activity. I recognize that there may be an EES II on the way that will extend key escrow to computer communications and perhaps increase the activity of the key escrow agents. On the other hand, presumably any Title III wiretaps of computer communications are already included in the estimated 4,00 wiretaps per year, so perhaps no. And for this, how much will it cost to operate the key escrow process? Does anyone know? I offer the above admittedly superficial analysis in the hope that the Administration will be forth coming with better document estimates to justify why it is so intent on proceeding so quickly down the key escrow path. I fear that the proposed EES is just a symptom of a process that seems out of control. One can only hope that the President's Interagency review of cryptography, that is expected to reach its conclusions soon, will recognize that there really is no need to proceed at such great speed and that the Administration and the public will be much better served by using a somewhat accelerated FIPS process, that makes use of public technical input, in establishing the U.S. public telephone security policy for the next twenty or thirty years. Slow down and look at the alternatives! We cannot afford not to! Sincerely, Stephen T. Walker cc: John Podesta 10/01/93 10:59 301 948 1784 NIST CSL 0007 THE DEPARTMENT OF COMMERCE WASHINGTON, DC 20230 November 14, 1988 MEMORANDUM TO THE HEADS OF EXECUTIVE DEPARTMENTS AND AGENCIES SUBJECT: Procedures for Waivers for the Federal Information Processing Standards (FIPS) Under Section 111(d) of the Federal Property and Administrative Services Act of 1949 (40 U.S.C. 759(d)) as amended by the Computer Security Act of 1987, I am authorized to approve standards for Federal computer systems, and to determine the extent to which such standards, which are issued as Federal Information Processing Standards (FIPS), should be compulsory and binding. It has been necessary from time to time to waive the use of these compulsory FIPS when compliance would adversely affect the accomplishment of an agency's mission or cause a major adverse financial impact on the agency which is not offset by Governmentwide savings. For some previously issued FIPS, I have already delegated to the heads of agencies the authority to waive the standards under certain conditions. However, for other FIPS I have retained the waiver authority. The provisions of the Computer Security Act of 1987 clarify the conditions for the delegation of waiver authority to the heads of departments and agencies. I think that these officials are best able to make the decisions about the impact of standards on agency mission and costs, and the efficiency of Government operations would be improved if these officials had the authority to waive standards when necessary. Therefore, I hereby delegate to you the authority to waive, under the conditions specified in the attached procedures, XXXXXXXXXXXXXXXXXXXXXXXXX subsequent FIPS that are compulsory XXXXXXXXXXXXXXXXXXXXXXXXX the acquisitions and management of XXXXXXXXXXXXXXXXXXXXXXXXX communications systems. You may XXX hand written XXXX only to a senior official designated XXX note withheld XXXX ) of title 44 of the U.S. Code. The XXX "lawyer-client" XXXX se previously issued mandatory FIPS XXX privilege by NIST XXXX XXX Dept. Of Commerce XXX XXXXXXXXXXXXXXXXXXXXXXXXX regarding this change, please contact XXXXXXXXXXXXXXXXXXXXXXXXX 4 Technology Building; National XXXXXXXXXXXXXXXXXXXXXXXXX Technology; Gaithersburg, MD 20899. C. William Verity Secretary of Commerce Attachment cc: Agency Senior Mgmt Officials and Technical Contacts for ADP Stds Senior Officials for Information Resource Mgmt
10/01/93 10:59 301 948 1784 NIST CSL 0008 THE DEPARTMENT OF COMMERCE WASHINGTON, DC 20230 November 14, 1988 MEMORANDUM TO THE HEADS OF EXECUTIVE DEPARTMENTS AND AGENCIES SUBJECT: Procedures for Waivers for the Federal Information Processing Standards (FIPS) Under Section 111(d) of the Federal Property and Administrative Services Act of 1949 (40 U.S.C. 759(d)) as amended by the Computer Security Act of 1987, I am authorized to approve standards for Federal computer systems, and to determine the extent to which such standards, which are issued as Federal Information Processing Standards (FIPS), should be compulsory and binding. It has been necessary from time to time to waive the use of these compulsory FIPS when compliance would adversely affect the accomplishment of an agency's mission or cause a major adverse financial impact on the agency which is not offset by Governmentwide savings. For some previously issued FIPS, I have already delegated to the heads of agencies the authority to waive the standards under certain conditions. However, for other FIPS I have retained the waiver authority. The provisions of the Computer Security Act of 1987 clarify the conditions for the delegation of waiver authority to the heads of departments and agencies. I think that these officials are best able to make the decisions about the impact of standards on agency mission and costs, and the efficiency of Government operations would be improved if these officials had the authority to waive standards when necessary. Therefore, I hereby delegate to you the authority to waive, under the conditions specified in the attached procedures, previously issued and all subsequent FIPS that are compulsory for Federal agency use in the acquisitions and management of computers and related telecommunications systems. You may redelegate this authority only to a senior official designated pursuant to section 3506(b) of title 44 of the U.S. Code. The procedures for waiving these previously issued mandatory FIPS are attached. If you have any questions regarding this change, please contact James H. Burrows, Room B154 Technology Building; National Institute of Standards and Technology; Gaithersburg, MD 20899. C. William Verity Secretary of Commerce Attachment cc: Agency Senior Mgmt Officials and Technical Contacts for ADP Stds Senior Officials for Information Resource Mgmt
The Clinton administration has been constantly asking for proof that encryption products from other countries compete with US products. Foreign companies can compete both abroad and in our own domestic market because of the twisted Clinton policies. US companies are forbidden to export. Thus, it should come as no surprise that the Commerce Department maintained its own list of foreign encryption companies. Simply put, they already knew. Attached is a list of such companies and countries forced from the Department of Commerce's own records by Freedom of Information Act:
Company Name Country ---------------------------------------- Eracom Pty Ltd. Austrialia Cryptech Belgium Okio Data Canada Cryptomathic A/S Denmark Computer Elektronik Infosys Gmbh Germany Uti-Maco Software Gmbh Germany Algorithmic Research Ltd Israel Concord-Eracom Nederland Netherlands Philips Netherlands Askri Russia Sonnor Crypto AB Sweden British Telecom UK Business Simulations UK Compuserve UK Computer Security LTD UK Data Innovation LTD UK Dynatech Communications UK International Data Security UK IT Security International UK John Vale UK JPY Associates UK Microexpert UK Microft UK Micronyx UK PC Security UK Plessey Crypto UK Prosoft Limited UK Racal-Guardata UK Software Security UK Sophos LTD UK Sypro UK Zergo UK The following countries have no restrictions on the import of encryption: Belgium Brazil Germany Italy Malaysia Netherlands Spain Sweden Switzerland Taiwan Thailand United Kingdom
All content COPYRIGHT SOFTWAR (C) 2003. Any reproduction or use of content herein must be approved by SOFTWAR.