28 July 1998: Add Peter Harter e-mail quote.

22 July 1998
Source: Thanks for hardcopy from Electronic Privacy Information Center

EPIC obtained these documents by FOIA request. See related news report: http://jya.com/nsa-lsa.htm

We spoke about this release with Peter Harter, Global Public Policy Counsel for Netscape: "I have no problem with your publication but my preference is to publish all KMI plans at the same time and not isolate one company from another." We agree and welcome other Key Management Infrastructure (KMI) export presentations/applications, which, we understand have been made by IBM, HP, RSA, TMI, and others.

[Double fax headers on all pages except last; omitted hereafter.]

03/03/97 MON 10:51 FAX 202 456 9340   INTEL PROGRAMS   >>>EDFORS         [PAGE #]
SENT BY:Xerox Telecopier 7021 : 2-28-97 : 12:58  :    ->   202 456 9340: # [PAGE]


FACSIMILE: (602) 257-5299
VERIFICATION: (602) 257-5287

FACSIMILE (011-7-501) 258-5251

WASHINGTON, D.C. 20036-1796

XEROX 7032 (202) 429-3902
XEROX 7032 (202) 429-3903
XEROX 7021 (202) 429-3904
TELEX NO 89-2503
VERIFICATION (202) 429-8152

(202) 429-3000
FACSIMILE: (202) 429-3902
TELEX: 89-2503

IMPORTANT: This facsimile is intended only for the use of the individual or entity to which it is addressed. It may contain information that is privileged, confidential, or otherwise protected from disclosure under applicable law. If the reader of this transmission is not the intended recipient or the employee or agent responsible for delivering the transmission to the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this transmission or its contents is strictly prohibited. If you received this transmission in error, please notify us by telephoning and return the original transmission to us at the above address.


Name: PETER LICHTENBAUM                                                                                                   

Request Made On Date: February 28, 1997         Time: 12:57 PM      

Completion Required By Date: February 28, 1997         Time: ASAP            


Name: ED APPEL and BRUCE MCCONNELL                                                                           

Organization or Firm: NATIONAL SECURITY COUNCIL                                                          

Telecopy Phone Number: 456-9340        Verification Number :                                                  

Special Instructions

Total Pages & Cover Sheet:  16               Date Transmitted:                                                          

S&J Operator's name: CJACKSON         Telephone Number: 202-429-8052                               

Client/Case Number: 112190001                                                                                                    



TELEPHONE: (602) 257-5200
FACSIMILE: (602) 257-5299

(202) 429-5259

WASHINGTON, D.C. 20036-1796

(202) 429-3000
FACSIMILE: (202) 429-3902
TELEX: 89-2503


TELEPHONE: 011-7-501-258-5850
FACSIMILE (011-7-501) 258-5251


                                                    February 28, 1997


     TO:       Ed Appel
               National Security Council

               Bruce McConnell
               Office of Management and Budget

     FROM:     Peter Lichtenbaum

     RE:       Netscape -- Taher Elgamal Presentation


               In connection with Taher Elgamal's presentation to the

     Inter-agency Working Group (IWG) on Monday afternoon, attached is

     a copy of a paper that provides the basis for his presentation.

               Please give me a call if you have any questions.

               Best regards,


[Note: paragraph numbering is irregular in original; figures rough due to multiple faxes]


"Key Recovery and Export Licensing Proposal"

Taher Elgamal

Amended Version 0.9 - February 19, 1997

DRAFT - Netscape Confidential
[By hand:] (Netscape counsel agreed with release.)


This is a proposal from Netscape Communications Corporation regarding key recovery features in its client and server products. A business timeline is included.

Executive Summary

The key recovery proposal consists of two separate parts. The first part addresses the secure mail (S/MIME) keys (and keys for other local applications) and the second part addresses the SSL keys and related issues. Where possible, Netscape plans to offer voluntary recovery features for some encryption private keys. Corporate customers can define their own key recovery policies. They may decide to require key recovery for email applications as well as any other application that stores encrypted files on local or network disks.

Support for escrow of encryption private keys may be achieved as follows: Netscape client and server products offer Certificate Authorities the capability to only issue a certificate after the private key has been escrowed with an entity chosen by the Intranet administrator for security policy. The certificate will indicate that the corresponding private key has been escrowed.

The proposed plan for SSL does not use explicit escrow for SSL keys at the client or the server sides. Rather, since SSL only encrypts data between the client and the server such that the decrypted data is available on the server (and clients in some cases), other entities can obtain the data from the server directly in the case access to the plain text data is needed.

[Footer at 14 nscp-pages; hereafter omitted:]
Contains Netscape Proprietary Information - Not Subject to Release Under FOIA


2. Executive Summary (Cont'd)

The main point stressed here is that key recovery is useful for applications that enable storage of encrypted data and should be offered (as an optional feature) in a product line, but may not actually provide the desired result in some other applications. A plan that attempts to escrow all keys under all scenarios is perhaps too general and will face issues with scalability, distribution and legal issues with the escrowed private keys.

Recovery of Encrypted Secure Email Messages and Encrypted Data Files

This section outlines the steps involved in providing key or data recovery services for Secure Email and other applications that store encrypted data, for use by companies and other Intranet situations.

Figure 1 depicts the basic steps for issuing digital certificates while saving the encryption private keys. The escrow entity is not necessarily the same entity as the Certificate Authority since the two functions carry different scopes of responsibility. However, a company can decide to make them the same. An Intranet is defined here to be any group of end users that would like to connect certain servers, such as inside an enterprise or online banking servers.

The same options can be offered to end users that do not necessarily belong to an Intranet through optional services from ISPs and others. This can be sold as a method for the end user to retrieve their private keys in case of loss of a password or a similar event.

It is important to point out that the discussion here is specific to private keys that are used for encryption or key exchange only. These keys are used for the sole purpose of providing confidentiality features, rather than for authentication or integrity purposes. In no system will escrow or recovery services be offered for signature private keys.


3. Recovery of Encrypted Secure Email Messages and Encrypted Data Files (Cont'd)

The products will offer users the capability to distribute the private keys among several people or entities in case recovery is needed. Utilization of this feature will be a policy option for the administrator of the Intranet. Such a policy may require the collaboration of any M out of N people to collaborate in order to use the private key for recovery of stored encrypted data.

Figure 1

Enforcing the use of escrow

It will be possible for an enterprise to enforce a key recovery policy through policy modules that force the client to use a certain level of encryption only when all the recipients of the message have keys escrowed at a particular location (or locations). This is achieved using a trust policy module that offers the following options:


3.1 Enforcing the use of escrow (Cont'd)

User profiles are exchanged between correspondents as signed messages so that each user can determine the capabilities and policies of the other recipients. The combination of the certificate and user profiles determine the bit length used to encrypt the message. For example, Figure 2 provides an illustration of a secure email exchange where the recipient's encryption private key is escrowed. The sender checks the local policy and starts the process as illustrated.

Figure 2

Accessing Encrypted Email and files

The encrypted files and stored (or intercepted) email messages can be retrieved using the following procedure. After receiving a required form of proof of the right to get the data, the escrow facility uses its private key to internally retrieve the appropriate keys and uses those to retrieve the file or email message encryption keys used to encrypt the data. The private keys should never be exposed even to administrators, rather the system should automatically produce the message encryption keys. Either party can then decrypt the encrypted data to obtain the original plain text data.


3.2 Accessing Encrypted Email and files (Cont'd)

For example, Figure 3 depicts a process by which such access may take place. The specific processes will be determined by the local policies, economics and business models of the different parties.

Figure 3

Subsequent to the recovery request being processed, whether or not it is accepted, both sides must keep records of all such activities for liability and accounting purposes.


Certificate formats

The certificates used in the email system or for local stored files operations include the following special fields to reflect the fact that the corresponding private key has been escrowed.

Secure Socket Layer (SSL) Recovery Tasks

The other major use of encryption in Netscape's products is the use of the SSL protocol to connect clients to a variety of servers such as the web (Enterprise) server, the Collabra (News) server or the mail (Messaging) server. SSL is basically used for securing the connection between the client and the server and not for any encryption on the server (or the client) itself. Some servers support SSL currently while others will include the SSL support in the future.

There is no explicit support for escrowing SSL keys in this proposal for the reasons outlined below. However, SSL session data can still be acquired with the appropriate authorization. The mechanism for acquiring SSL session data is describe first, with the remainder of the section devoted to the issues involved if we were to explicitly escrow SSL session keys for either the client or the servers. There are also general issues involved in the use of escrow in protocols that use encrypted communications, but those details are outside the scope of this document.


Proposal for accessing data communicated using the SSL protocol

The main point stressed in this section is that SSL does not encrypt the data on any machine, and therefore will not prevent any law enforcement agency or other entity that needs access to the data from obtaining that access through the server. The key points are summarized below:

Issues with escrowing keys in the SSL protocol

There are many technical reasons that prevent a practical system for escrowing SSL keys while maintaining the integrity and the performance of the system.

Sessions Keys in SSL:

The SSL session keys are generated using some known numbers to the client and the server in lock step. The SSL protocol does not actually send the session keys at all. This is both for performance and security reasons.

If the SSL protocol were to be modified to allow for sending encrypted versions of the session keys, the performance impact on the clients and servers would be so high that most customers will try to find alternative solutions. This due to the known fact that public-private key operations consume most of the time during the establishment of a secure session. To achieve the escrow functionality, the client and server software will have to, during each session or group of sessions, perform additional public and/or private key operation[s] to encrypt message keys using keys of escrow entities. There is also additional overhead in verifying the validity of the escrow entity of both the client and the server which requires yet more public-private key operations as well as making policy decisions on how many bits of encryption keys to use.


4.2.1 Sessions Keys in SSL (Cont'd)

There is also a security problem involved with sending a lot of keys encrypted under a single public key for the escrow entity. The private key of the escrow entity will become a target for all "hackers" and code breakers who will have a lot of plain text - cipher text pairs to work from.

Master Secrets in SSL:

The Master Secrets in SSL are used by the clients and servers to generate both the session keys (used for encryption) and the Message Authentication Code (MAC) secrets used to produce the MAC to ensure integrity of the SSL records. Note: If the Master Secret[s] were to be escrowed, the holder of the escrow keys would be able to make a modification of the original session that would look authentic. That activity makes the session basically invalid since it is easily repudiated by the owner of the key claiming that the escrow entity performed the modification to the session.

Server Private Keys in SSL:

The SSL server private key is used by the client to perform the exchange of the Master Secret. This may appear to be a key exchange function. However, the result of a correct reception of the Master Secret by the server automatically authenticates the server to the client. Thus, the SSL server private key also serves as an authentication key which makes the escrow function invalid because the authentication key is easily repudiated by the owner of the key claiming that the escrow entity performed the signature.

Note that escrowing a signature or an authentication private key should not be considered by any system. That activity makes a signature basically invalid since it is easily repudiated by the owner of the key claiming that the escrow entity performed the signature.

Client Private Keys in SSL:

The SSL client private keys are only used for signatures and thus not suitable for escrow. Besides, knowing these keys does not provide any capability to obtain the plain text data.

Unauthenticated Clients in SSL:

This is perhaps the SSL feature that makes escrow of any keys that control the SSL traffic unusable. Today, the vast majority of the SSL sessions do not use client authentication. That implies that even with the acquisition of all the data during a particular SSL session, there really is no deterministic way of linking a session to any particular client or person. Unlike phone tapping, there is nothing in the SSL to track down that would let anyone recognize the client (person). Depending on IP addresses, DNS names or any other Internet-based quantity is never guaranteed to provide enough data to find a link to a particular person.


4.2.5 Unauthenticated clients in SSL (Cont'd)

The only practical way, it seems, is to get to the server and check whether the session is linked to some user name - password recognized by the server for some authentication of the client. Since getting to the server is the only real practical way to get enough information about the client, then an appropriate policy is a mechanism to obtain copies of the entire sessions with particular clients, if the server is informed by the law enforcement agency or other interested entity about the activities of a particular individual or group.

Time Line and Business Issues (Milestones for 1998/1999)

The current (and future) product offerings from Netscape fall under the appropriate class of products that provide data recovery for SSL sessions according to the definitions in the previous sections. The SSL offerings in the various Netscape servers will continue to grow, but will always support the same paradigm of the availability of the data on the server.

As far as the S/MIME key recovery mechanism discussed earlier, the implementation plan goes as follows:

Q1 98 - Planned first introduction of a Certificate Server with recovery capabilities.

Q2 98 - Planned introduction of S/MIME clients with basic recovery features; may not have all options for programming and configuring the email client for all possible policies.

Q1 99 - Planned implementation of more robust recovery features; also support for local file encryption applications.

Netscape will assign appropriate engineering, marketing, test and documentation resources to the above goals. Implemented data recovery features will be marketed to the customer base as well as new customers. Implementation of encryption private key escrow in the certificate server product will be according to the description in this document. Other servers and the client products will utilize the recovery features as they fit.


Other Export Related Matters

The following two sections outline the proposed architecture for the coming and following generations of Netscape products. We would like to obtain export licenses for these items for the upcoming releases of the client (Netscape Communicator) and server products.

These items are not directly tied into key recovery, but are included here for the purpose of obtaining the approvals to get export licenses on next generation products in a structured way. This architecture also provides us with a single product build that will simplify and streamline the product building process.

The Cryptography Configuration Module (CCM)

The CCM is a file signed by Netscape that provides the product installation with enough information about the allowed key lengths for the various applications requiring cryptography.

The overall format is a text file, which is digitally signed and packaged in a signed archive (JAR) file. The file consists of a sequence of lines of text. Each line contains a name/value part in the format NAME=VALUE. For each possible application/algorithm combination there will be a NAME/VALUE pair, where NAME describes the application/algorithm combination, and VALUE is a Boolean. A value of true indicates that the algorithm is allowed, and value of false indicates that it is not supported. In addition to Boolean values for crypt algorithms, other Boolean and string values are supported.

The format of the CCM is outlined below:

      Application #1 (e.g. SSL)
Algorithm suite #1                  Number of key bits (arbitrary for SSL)
Algorithm suite #2  Number of key bits (arbitrary for SSL)

[Omit duplicate of preceding page; apparently generated by restart of fax transmission as indicated by 16 minute time gap and restart of fax page numbering.]


6.1 Cryptography Configuration Module (CCM - (Cont'd)

      Application #2 (e.g. S/MIME)
Algorithm #1                  Number of key bits (56 bits for symmetric)
Algorithm #1 with recovery  Number of key bits (arbitrary with recovery)
Algorithm #2                  Number of key bits (512/1024 for public key)
Algorithm #2 with recovery  Number of key bits (arbitrary with recovery)

      Application #3 (e.g. Crypto APIs)
Algorithm #1                  Number of key bits (56 bits for symmetric)
Algorithm #1 with recovery  Number of key bits (arbitrary with recovery)
Algorithm #2                  Number of key bits (512/1024 for public key)
Algorithm #2 with recovery  Number of key bits (arbitrary with recovery)

      Countries of use

Enforcement flags

Signature of Netscape


6.1 Cryptography Configuration Module (CCM - (Cont'd)

The following table gives a specific example of an SSL section in a domestic CCM:
















The countries of use field is used as an extra check for improper exportation or importation of a CCM in a wrong country. This field can be checked against the country fields in certificates or escrow entity fields in certificates.

The enforcement flags can be used in certain countries according to local policies.


Cryptographic Service Provider (CSP) Interface

Netscape products will use a PKCS #11 interface for CSP's to attach to clients or servers to provide cryptographic functions. Refer to PKCS #11 specifications for more details. For export purposes the following measures are taken to address proper operation under the export laws.


6.2 Cryptographic Service Provider (CSP) Interface (Cont'd)

The following diagram, Figure 4, outlines the proposed architecture of the exportable versions of Netscape next generation products. This architecture uses a combination of key recovery, the Cryptographic Configuration Module and the filtering software so that only approved products work with the Netscape product offerings under the various export (and import in some cases) laws.

Figure 4 The Architecture of Exportable Netscape Products

[End Netscape presentation]

[Partly legible fax header; x=illegible]

xxxxxx  Xerox Telecopier 7021   xxxxxxx12:08            2024299304   33 x 4024 xxxxx

[By hand:] P126B

Distribution Arrangements Covering Strong Encryption/Remarks
#1 Ref. 913-96 Strong Encryption for Corporate Networks:
92 Fortune 500 Companies
-Filed 08 Aug96; with Joyce/NSA 19 Aug96
-New list of S/W and new algorithms Faxed to Joyce
-NSA Meeting @ NSCP 23 SEP96
-NSA Meeting @ NSCP 15 OCT96
-After discussion, we made amendments listing new S/W Quantities/Values,
 waiver of DSP-5 & DSP-83; this was Faxed to Joyce 03 DEC96
-NSA Meeting @ NSCP 17 DEC96
-Revision with Joyce 20 DEC96
As of 20 DEC, Joyce said her superior had talked to Deputy Director William Crowell and NSA wanted NSCP to consider selling /exporting products without triple-DES. Then, JAN97, Ref. 913-96 was returned without action.
#2 Ref. 914-96 Strong Encryption for Corporate Networks: Netscape and its Subsidiaries
-Filed 08 Aug96; with Joyce/NSA 19 Aug96
-New list of S/W and new algorithms Faxed to Joyce
-NSA Meeting @ NSCP 23 SEP96
-NSA Meeting @ NSCP 15 OCT96
-After discussion, NSA indicated this would be combined with Ref. 913-96 and we planned to Fax all approved amendments from 913-96 to comply & pertain to Ref. 914-96.
As of 20 DEC, Joyce said her superior had talked to Deputy Director William Crowell and NSA wanted NSCP to consider selling /exporting products without triple-DES. Then, JAN97, Ref. 914-96 was returned without action.
#3 Ref. 925-96 Strong Encryption for Financial Institutions: Banks and their Customers

-Filed 09 Aug96; with Joyce/NSA 19 Aug96
-New list of S/W Faxed to Joyce
-NSA Meeting @ NSCP 23 SEP96
-NSA asked us to provide explanation of how we would determine a bank was a responsible institution. We resolved what criteria would be.
-NSA Meeting @ NSCP 15 OCT96
-After discussion, NSA indicated they would first approve 913-96 and we planned to Fax all approved amendments from 913-96 to comply & pertain to Ref. 925-96.
As of 20 DEC, Joyce said her superior had talked to Deputy Director William Crowell and NSA wanted NSCP to consider selling /exporting products without triple-DES. Then, JAN97, Ref. 925-96 was returned without action.


    DEPARTMENT OF STATE           IS/FPO/CDR [Initials]      Date: 12/17/97

    (X) RELEASE    ( ) DECLASSIFY   | MR cases Only:
    ( ) EXCISE     ( ) DECLASSIFY   |  EO Citations _______________________  
    ( ) DENY             IN PART    |
    ( ) DELETE Non-Responsive Info  | _____________________TS authority to
    FOIA Exemptions________________ | ( ) CLASSIFY as     ( ) S or ( ) C
    PA   Exemptions________________ | ( ) Downgrade TS to ( ) S or ( ) C


FEB 07-1997  19:43           2024293904                xxx             P.03


Transcription and HTML by JYA/Urban Deadline