From: "Dave Banisar" <banisar@epic.org>
Date: Fri, 25 Aug 95 13:37:27 PDT
To: "Cypherpunks List" <cypherpunks@toad.com>
Subject: NIST Key Escrow Papers
Message-ID: <n1402753899.59250@epic.org>
MIME-Version: 1.0
Content-Type: text/plain


fyi...

----

August 25, 1995

MEMORANDUM FOR Registrants for the Sept. 6-7, 1995
               Key Escrow Issues Meeting

From:  NIST - Ed Roback

Subject:  Discussion Papers

Attached for your information are two discussion papers for the
upcoming September 6-7, 1995 Key Escrow Issues Meeting to be held
at NIST.  If you have any questions on this material, you may
reach me on 301-975-3696.  

I look forward to seeing you in September.  

Attachments
                    ------------------------

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.

8/25/95



_________________________________________________________________________
Subject: NIST Key Escrow Papers
_________________________________________________________________________
David Banisar (Banisar@epic.org)        *  202-544-9240 (tel)
Electronic Privacy Information Center   *  202-547-5482 (fax)
666 Pennsylvania Ave, SE, Suite 301     *  HTTP://epic.org
Washington, DC 20003                    *  ftp/gopher/wais cpsr.org