[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Another Son of Clipper discussion paper
I sent along two discussion papers for tomorrow's NIST session on the
revised plans for GAK last week. Here's the third.
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
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
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
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
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
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
- - -
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
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: [email protected]