I converted a document in some proprietary Windows binary format to ASCII. Formatting mistakes are mine. Ron Plesser is a very experienced lobbyist. He was involved in the passage of the ECPA, among other things. He's CIX's lawyer, and sent this document to CIX (the Commercial Internet Exchange), which passed it on to its membership. John Gilmore PIPER & MARBURY L.L.P. Memorandum To: Interested Parties From: Ron Plesser Date: September 11, 1995 Subject: NIST Key Escrow Encryption Meeting The National Institute of Standards and Technology on September 6 and 7 held a meeting on issues regarding key escrow encryption, focusing on export criteria for software and desirable characteristics for U.S. key escrow agents. Ten draft software key escrow export criteria were put forth by NIST for consideration and possible revision (see below). Key escrow encryption is the recent Administration proposal for an alternative to Clipper Chip, which industry opposed. Key escrow would, in the Administration's view, allow the export of software with strong encryption. In summary, the government would permit the general licensing of 64-bit-key encryption provided that it be manufactured with a key that would be maintained by independent escrow agents who were certified by the U.S. government. Foreign escrow agents could be used where there was a bi-lateral agreement with the particular country involved. NIST Deputy Director Ray Kammer provided an overview of the goals of the meeting, and said that NIST plans to issue a Federal Register notice containing a "revised set of thoughts" in three weeks. There will be a 60-day comment period following publication of the revised principles in the Federal Register. The NIST will then review the comments received and determine whether there is enough consensus to proceed. There will be additional meetings on September 15, 1995 to discuss the Federal government's requirements for its own information processing standards for key escrow encryption. This meeting will take place at the Gaithersburg, Maryland Hilton Hotel from 9:00 a.m. to 5:00 p.m. It was clear from the meeting, both in presentations and conversation during breaks, that most computer systems and certainly those used by large entities will have key escrow systems for encryption. There was even a person who spoke who said that they are doing this now. Many people at the meeting acknowledged that key escrow would be implemented at some point for domestic as well as for exported programs. The issue is who would hold the key. For example, could a company hold its own keys or could an independent agent be used? The people who create mass market software, however, still expressed significant opposition to key escrow. While the government went to some length to express that this solution is neutral as to software or hardware, it has to be acknowledged that hardware-based systems are easier to control. The subject that was not well discussed was encryption in relation to network services and the internet. It was discussed in relation to the issues of interoperability and the ability to decrypt both sides of a communication. The assumption that I and others had at the outset was that the Administration had made progress in the last year in raising itself from the ashes of Clipper Chip. By the end of the meeting that was not altogether clear. There will remain a great deal of controversy surrounding this issue. Congress is sure to get involved and it will get messier before it gets resolved. Administration Comments Mike Nelson, who is special assistant for information technology to the White House Office of Science and Technology Policy and co-chair of the inter-agency working group on encryption, provided a historical overview of the data encryption issue. He said that the proposed 64-bit-key encryption is 17 million times stronger than the 40-bit-key encryption currently allowed to be exported. Under the proposed policy, software with 64-bit-key encryption could be exported to friendly countries under certain conditions, all of which require that a key to that encryption be available in the U.S. from an independent third-party. Mr. Nelson stated that the new policy will open up new market opportunities for the U.S. computer software industry, and that key escrow has the potential to become a de facto global standard. The Administration policy for 40-bit-key encryption will continue as-is, and no keys will have to be escrowed for such systems. Mr. Nelson said that the government's main concern is that strong encr In response to questioning, Mr. Nelson stated that the 64-bit-key limit is being imposed because the government is not certain that the key escrow system will work. Once the system is up and running, longer keys may be allowable. He said that the draft criteria are based on national security needs, and that they were pushed as far as possible to meet commercial needs. Mr. Nelson added that the Administration is discussing the possibility of federal legislation with Hill staff to avoid varying state laws on encryption. Industry Perspectives General reaction was mixed to the government's proposal. Most heavy industrial and commercial users of encryption seemed accepting of the Administration's position. To them this meant greater flexibility and would mean that most larger systems could get export licenses for 64-bit-key systems and this would expand the capacity to sell larger systems abroad. This position was exemplified by Trusted Information Systems (TIS), representatives of which spoke several times. In a presentation, Peter Dinsmore of TIS offered restatements of the criteria to make them more commercially viable, and a set of "criteria for the criteria," which are as follows: 1) don't specify commercial criteria, 2) don't exceed the minimum, 3) don't allow criteria creep, 4) don't solve the dual-rogue problem, 5) don't over protect, and 6) use generic nomenclature. He recommended that criteria six and nine be removed altogether, a view that was echoed by other participants. The mass market software industry and the public interest groups were very opposed to the Administration proposal. They do not believe that 64-bit key is sufficient, and they do not believe that anyone will buy U.S.-manufactured software with a key that is to be held by a third party under at least some control by the government. There was a fair amount of confusion on the issue at the meeting, but it now seems clear that the government would permit foreign escrow where there are bi-lateral agreements with friendly nations. In a presentation, Bob Holleyman of the Business Software Alliance criticized the Administration's failure to "liberalize export controls on generally available software employing non-key escrow encryption." Also, he stated that the Administration's proposal and the draft criteria "continue to reflect a misunderstanding of the market place and, if implemented in anything like their current form, will prevent key escrow encryption from ever being commercially adopted." Mr. Holleyman r In addition, the representative of MCI strongly objected to the proposal as an incursion into the private sector and as an impediment to the development of a strong information infrastructure. Encryption guru Whit Diffie of Sun Micro Systems and others objected to the proposal. Danny Weitzner of the Center for Democracy and Technology said that CDT was going to go to Congress and object to the implementation of this proposal. They thought that it was a bad deal and the government should not be placed in the position of directing standards and requiring back doors into encryption systems. Discussion of Criteria Six, Seven and Eight Following the industry presentations, participants divided into groups to discuss various criteria. The group that discussed criteria six, seven and eight made the following observations and recommendations. There seemed to be universal objection to criterion six. This would limit the interoperability of systems. It effectively states that exported 64-bit key cannot be used to decrypt messages that were encrypted with a higher value. This would make it very difficult for U.S. companies to interact with foreign subsidiaries. The internet would find great difficulty in connection with this criteria. Regarding criterion seven, concern was raised that in the context of e-mail, it would be onerous to do key escrow for every transmission. Concern also was raised about maintaining the integrity of intellectual property in instances in which the escrow agent is in a foreign country. In effect, when one chooses an escrow center, one also is selecting a legal system. A request was made for a supplemental document explaining applicable existing laws. Concern was raised that all of the criteria are focused on the voice communication paradigm, rather than on the dynamic data communications environment. Laws also are focused on this paradigm, and law moves slowly whereas computer technology moves rapidly. In addition, the criteria do not address varying international laws on issues such as privacy. Companies will have to comply with the laws of the strictest countries. Concern was raised that privacy considerations are not as apparent in the criteria as ease of access by law enforcement agencies. Also, innocent parties could be de-escrowed. In addition, it was emphasized that encryption must not interfere with use of existing software. Information was requested on two encryption schemes, Banker's Trust and Fortress. It was recommended that the TIS restatement of criterion seven be adopted. This restatement is as follows: "The key escrow mechanism allows access to both sides of a simultaneous (i.e., two-way) communication with only access to the decrypting information from one of the users." It also was recommended that for bi-directional communications, both parties negotiate a common key and escrow it, and that for one way communications, the sender select the escrow key. Regarding criterion eight, it was agreed that the technology issues, international issues, and privacy issues are the same as those for criterion seven. It was noted that certain implementations would require escrowing of the session key, which is unrealistic. It was agreed that with one court order, law enforcement agencies should have the ability to decrypt a stream of messages. However, there must be a time limit on decryption. It was agreed that agents should be able to implement an automated system. General Review/Comments on All Criteria Industry and government representatives met less formally with the objective of reviewing each of the criteria and attempting to reconcile differences. However, this did not occur; instead, broader issues were discussed. There was a certain amount of tension during this session, as each side complained that the other did not understand its needs. Industry members said that it seemed that implementation of the draft criteria, or a version thereof, is a foregone conclusion on the part of government, without industry input concerning the entire concept. Specifically, industry members challenged the 64-bit maximum as being arbitrary and unnecessary. They said that although 56-bit encryption was discussed with government last year, technology moves rapidly, and now 64 bits are not enough. A NIST representative countered that the National Security Agency is "putting a big card on the table" with 64 bits. Industry members also protested that the criteria do not meet the needs of the global marketplace. Consumers will not buy products designed to meet these criteria because they already have access to 64-bit encryption with no keys either free or at a low cost. They argued that the scope of the criteria (e.g., criterion nine) is broader than the stated objective of exportability, and requested more information as to why each criterion is being proposed. Concern also was raised that foreign countries with bi-lateral agreements with the U.S. will act against U.S. key escrow agents. Also, industry will not know the terms of these agreements. Export Procedures Officials of Department of State and the Department of Commerce explained in general terms how this program would work. Each application would go first to the State Department for a jurisdictional certification on technical aspects. If State were satisfied that the criteria had been met, then it would certify the application over to the Commerce Department for general licensing procedures. There would also be an escrow package, that would have to be certified. It was not clear who would control the certification of escrow agents. Escrow Agents The issue of who could be an escrow agent and how they would be controlled was discussed, but not resolved. The issues of liability for wrongful release, the conditions of release, and related questions were not resolved. It seemed clear to me that escrow agents would have to be independent of the user entity. If this law firm were to use an encryption package in its London office, the key would have to be placed with a third party. Conclusion While no issues were resolved at the meeting, it provided a valauble forum for the exchange of ideas between government and industry. Focus now turns to Congress, and to the crafting of a constructive response to the upcoming Federal Register notice. The Administration seems open to changes. The mass market software industry and the public interest community seem negative. We will continue to keep you informed. --- Draft Export Criteria --- for Software Key Escrow Encryption Software key escrow encryption products meeting the following criteria will be granted special export licensing treatment similar to that afforded other mass-market software products with encryption. 1. The product will use an unclassified encryption algorithm (e.g., DES, RC4) with a key length not to exceed 64 bits. 2. The product shall be designed to prevent multiple encryption (e.g., triple-DES). 3. The key required to decrypt each message or file shall be accessible through a key escrow mechanism in the product, and such keys will be escrowed during manufacture in accordance with #10. If such keys are not escrowed during manufacture, the product shall be inoperable until the key is escrowed in accordance with #10. 4. The key escrow mechanism shall be designed to include with each encrypted message or file, in a format accessible by authorized entities, the identity of the key escrow agent(s), and information sufficient for the escrow agent(s) to identify the key or key components required to decrypt that message. 5. The product shall be resistant to any alteration that would disable or circumvent the key escrow mechanism, to include being designed so that the key escrow mechanism cannot be disabled by a static patch, (i.e., the replacement of a block of code by a modified block). 6. The product shall not decrypt messages or files encrypted by non-escrowed products, including products whose key escrow mechanisms have been altered or disabled. 7. The key escrow mechanism allows access to a user's encrypted information regardless of whether that user is the sender or the intended recipient of the encrypted information. 8. The key escrow mechanism shall not require repeated involvement by the escrow agents for the recovery of multiple decryption keys during the period of authorized access. 9. In the event any such product is or may be available in the United States, each production copy of the software shall either have a unique key required for decrypting messages or files that is escrowed in accordance with #10, or have the capability for its escrow mechanism to be rekeyed and any new key to be escrowed in accordance with #10. 10. The product shall accept escrow of its key(s) only with escrow agents certified by the U.S. Government or by foreign governments with which the U.S. Government has formal agreements consistent with U.S. law enforcement and national security requirements. Note: Software products incorporating additional encryption methods other than key escrow encryption methods will be evaluated for export on the basis of each encryption method included, as is already the case with existing products. Accordingly, these criteria apply only to the key escrow encryption method incorporated by a software product, and not to other non-escrowed encryption methods it may incorporate. For instance, non-escrowed encryption using a key length of 40 bits or less will continue to be exportable under existing export regulations. - Please also review discussion paper #1 (distributed earlier), which raises a number of issues involving exportability criteria and how exportable products could be designed. Discussion paper #2 (also previously distributed) presents questions involving key escrow agents. ~WASH01A:49767:1:|09/11/95 1-10