[Outlines of talks by Raymond Kammer and Michael Nelson on
   Key Escrow Issues Meeting, at NIST, Gaithersburg, Maryland,
   September 6, 1995.]


   Goals and Objectives:
   Software Key Escrow Issues Meeting

   Raymond G. Kammer, Deputy Director National Institute of
   Standards and Technology

   September 6-7, 1995


   Perspective

   1.   Last year, we held two workshops on key escrow issues.
        A fundamental question was raised:

          Can a software key escrow method be bound to an
          encryption algorithm in a robust manner to permit
          export of strong algorithms (e.g., DES)?

   2.   On August 17, 1995, the Administration announced that
        it would permit the export of software encryption with
        64-bit key space if the key(s) required for decryption
        were escrowed with approved escrow agents.

   3.   Given parameters in #2, draft export criteria have
        been developed. See Discussion paper #2. (Dr. Nelson
        will review in next presentation.)


   Goals and Objectives

   During the course of this meeting, we would like to:

   1)   understand industry reaction to the draft export
        criteria; For example, are they clear,
        straightforward, consistent and implementable?

   2)   begin a dialog to finalize the criteria and establish
        the procedural/regulatory changes in a timely manner;

   3)   explain how the USG envisions the export process
        working for these software products;

   4)   listen to industry's concerns on issues requiring
        attention so we can focus our activities to be as
        responsive as possible;

   5)   discuss issues involving desirable characteristics for
        key escrow agents and approaches to developing and
        implementing an approval process;

   6)   provide industry the opportunity to express its
        concerns on issues related to key escrow encryption

   7)   identify areas for follow-up discussion / meetings.

   Questions?

   [End Kammer]

----------

   Draft Software Key Escrow Export Criteria

   Michael Nelson
   [White House Office of Science and Technology Policy]

   presented to the:
   Software Key Escrow Issues Meeting
   National Institute of Standards and Technology

   September 6-7, 1995


   Historical Perspective

   On July 20, 1994, Vice President Gore wrote to then Rep.
   Maria Cantwell of establishing a goal:

        of trying to develop a key escrow system that will
        provide strong encryption, be acceptable to commercial
        users worldwide, and address our national security
        needs as well.

   He also stated:

        Such a key escrow system would be implementable in
        software, firmware, hardware, or any combination
        thereof, would not rely upon a classified algorithm,
        would be voluntary, and would be exportable.

   In 1994, two Key Escrow Alternatives meetings were held by
   NIST to discuss alternatives to Clipper. Five key questions
   were raised:

   1.   Has NSA determined that there is no way of binding a
        software key escrow method to an algorithm in a manner
        that will be robust enough to permit export of strong
        encryption (e.g., DES)?

   2.   If NSA believes that software can be used effectively,
        will they try to work with industry to define
        acceptability criteria based upon the strength of the
        algorithms to be used?

   3.   Does NSA anticipate foreign governments allowing use
        of U.S. controlled (read "escrowed") cryptography?
        Specifically, does the NSA envision U.S. escrow of
        keys for U.S.-originated cryptography used in other
        countries?

   4.   Can key escrow products be freely exported provided
        that no algorithms are included, with the anticipation
        that foreign users can insert their own algorithms?

   5.   Provided that software solutions are acceptable, what
        will the evaluation or approval process look like? Is
        it a one-time review?

   We believe that the draft export criteria address most, if
   not all, of these questions.


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


   Conclusions and Summary

   1.   We welcome the opportunity to work with you to refine,
        clarify and finalize the export criteria for 64-bit
        software key escrow encryption.

   2.   We also need your thoughts on desirable
        characteristics for key escrow agents and what sort of
        approval process should be established.

   3.   We need to understand your priorities for government
        activities to make all of this happen.

   4.   As we move forward, let us not lose sight of our
        concerns to provide strong encryption that meets users
        needs and does not harm national security and law
        enforcement

   [End Nelson]