From: John Gilmore <gnu@toad.com>
Date: Wed, 13 Sep 95 19:19:19 PDT
To: cypherpunks, gnu
Subject: Ron Plesser's take on NIST GAK meeting
Message-ID: <9509140219.AA09487@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


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