From: Jim Gillogly <jim@rand.org>
Date: Tue, 5 Sep 95 13:54:02 PDT
To: cypherpunks@toad.com
Subject: Another Son of Clipper discussion paper
Message-ID: <199509052053.NAA01226@mycroft.rand.org>
MIME-Version: 1.0
Content-Type: text/plain


I sent along two discussion papers for tomorrow's NIST session on the
revised plans for GAK last week.  Here's the third.

	Jim Gillogly
	Hevensday, 14 Halimath S.R. 1995, 20:49
-----------------------------------------------------------------------------

Key Escrow Issues Meeting, September 6-7, 1995
Discussion Paper #3

                 Export Criteria Discussion Draft --
                64-bit Software Key Escrow Encryption

As discussed at the SPA/AEA meeting on August 17, 1995, the
Administration is willing to allow the export of software
encryption provided that the products use algorithms with key
space that does not exceed 64 bits and the key(s) required to
decrypt messages/files are escrowed with approved escrow agents.
On the same date, the September 6-7 key escrow issues meeting at
NIST was also announced.  The two principal topics at the meeting
will be:  discussion of issues of exportability of 64-bit
software key escrow encryption and 2) desirable characteristics
for key escrow agents.

In order to help make most productive use of the limited time
available at the upcoming meeting and to better focus
deliberation, the following criteria are being distributed for
discussion purposes.  Since it is important that final criteria
be clear, straightforward, consistent, and implementable, please
review these draft criteria and be prepared to discuss
how they may be refined and made more specific.

                          --- 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.

Note:  These issues will be discussed at the Key Escrow Issues
Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at
the National Institute of Standards and Technology (Gaithersburg,
Maryland).  The meeting will be open to the public, although
seating is limited.  Advance registration is requested, please
contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e-
mail: carlton@micf.nist.gov.

9/1/95
-----------------------------------------------------------------------------