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.


Return to the CDT Crypto Page
Return to the CDT Home Page