From: Flame Remailer <remailer@flame.alias.net>
Date: Tue, 29 Aug 95 22:51:38 PDT
To: cypherpunks@toad.com
Subject: NIST Key Escrow meeting
Message-ID: <199508300551.HAA17047@utopia.hacktic.nl>
MIME-Version: 1.0
Content-Type: text/plain


Subject: NIST Key Escrow Meeting Discussion Papers

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


                      Issues -- Export of
                 Software Key Escrowed Encryption


On August 17, 1995, the Administration announced its proposal to
permit the ready 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.  Under the proposal,
products will be reviewed to verify that they satisfy the
criteria and, if so, they will be transferred to the Commodity
Control List administered by the Department of Commerce where the
products can be exported under a general license (in much the
same way that 40-bit RC2/RC4 encryption is licensed today).

We are working toward creating broadly stated criteria that are
in the nature of performance specifications.  To meet these
criteria, encryption products will need to implement key escrow
mechanisms that cannot be readily altered or bypassed so as to
defeat the purposes of key escrowing.

The criteria, when finalized and published, will state the
objectives, but not the exact technical method(s), by which those
objectives are satisfied.  This is to provide software publishers
the flexibility to design methods for meeting our stated
objectives in a manner that is compatible with the design of
their products.  There are, therefore, a number of questions we
must work together to answer in order to draft effective
criteria.  These questions are:

*    Avoiding multiple encryption -- How can the product be
     designed so as to prevent doubling (or tripling, etc.) the
     key space of the algorithm?

*    Disabling the key escrow mechanism -- How can products be
     made resistant to alteration that would disable or
     circumvent the key escrow mechanism?  How can the "static
     patch" problem be avoided?  How can this be tested?

*    Access to escrow information -- What mechanisms must be
     designed into encryption products to allow authorized access
     to escrowed keys?  This likely includes the identity of the
     key escrow agent(s) and a serial number for the key escrow
     agent to use to identify the key(s)/component(s) necessary
     to decrypt the message.  What other information will be
     necessary to be provided to the escrow agent to identify the
     necessary key(s)/component(s)?  Are there other comparable
     viable approaches?

*    Non-escrowed use -- How can products be made so that they do
     not function with non-escrowed products (or tampered
     escrowed products)?  How can this be tested?

*    Limiting surveillance -- How can products be designed so
     that information both sent and received by the user can be
     decrypted without release of keys of other users?

*    Practical Key Access -- How can mechanisms be designed so
     that repeated involvement of escrow agents is not required
     for decryption for multiple files/messages during the
     specified access period?

*    Assurance that keys are escrowed -- How can it be assured
     that key escrow products are indeed satisfactorily escrowed?
     For example, products could be required to be escrowed at
     time of manufacture or be made inoperable until properly
     escrowed.

*    Ability to re-escrow keys -- How can products be designed so
     that new keys can be escrowed at the user's discretion with
     a U.S. Government approved escrow agent?

*    Certified escrow agents -- Can products be designed so that
     only escrow agents certified by the U.S. government
     (domestic, or under suitable arrangements, foreign) are
     utilized?  What should be the criteria for an acceptable
     U.S. escrow agent?

                         --------------

With your input, we are hopeful that this effort will lead to
definitive criteria, which will facilitate the development of
exportable products and help minimize the time required to obtain
export licenses.  The Administration seeks to finalize such
criteria and make formal conforming modifications to the export
regulations before the end of 1995.


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.


8/25/94

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


                      Discussion Issues:
         Desirable Characteristics for Key Escrow Agents


In the government's recent announcement of its intent to allow
the export of 64-bit software key escrow encryption products, one
stipulation was that the keys would be escrowed with an approved
key escrow agent.(*1)  Exactly what qualifications/considerations
are appropriate for approval as a key escrow agent have not been
defined.  Some of the issues which need to be discussed and
resolved include the following:

*    What kinds of organizations should be excluded from
     consideration as approved key escrow agents?

*    What sort of legal agreement between the government and the
     key escrow agent is necessary to stipulate the
     responsibilities of the agent?  Should this include the
     terms and conditions under which release of a key is
     required?

*    How will liability for unauthorized release of key be
     handled?

*    Should, for example, intentionally misreleasing or
     destroying a key be criminalized?  Should this include other
     actions?

*    How can the government's needs for confidentiality of key
     release be handled?

*    Should approval of key escrow agents be tied to a public key
     infrastructure (for digital signatures and other purposes)?

*    What procedures need to be developed for the storage and
     safeguarding of keys?

*    What are the acceptable performance criteria (e.g., around-
     the-clock availability, accessibility, reliability, etc.)
     for approved key escrow agents?

*    Under what circumstances will key escrow agents in foreign
     countries be approved?

*    What process will be used to approve escrow agents?
     Costs/who pays?
---------
(*1)  "Approved," for the purposes of this discussion, means that
the government (or its agent) has formally granted permission for
an organization to hold keys for exportable encryption products.


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.