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]

> | STEPTOE & JOHNSON LLP ATTORNEYS AT LAW |
> PHOENIX, ARIZONA FACSIMILE: (602) 257-5299 VERIFICATION: (602) 257-5287 MOSCOW, RUSSIA FACSIMILE (011-7-501) 258-5251 | 1300 CONNECTICUT AVENUE, N.W. 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.

> FROM Name: PETER LICHTENBAUM

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

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

> DELIVER TO

> 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

> | STEPTOE & JOHNSON LLP ATTORNEYS AT LAW |
> PHOENIX, ARIZONA TWO RENAISSANCE SQUARE TELEPHONE: (602) 257-5200 FACSIMILE: (602) 257-5299 PETER LICHTENBAUM
> (202) 429-5259

> 1300 CONNECTICUT AVENUE, N.W.
> WASHINGTON, D.C. 20036-1796

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

> STEPTOE & JOHNSON INTERNATIONAL
> AFFILIATE IN MOSCOW, RUSSIA

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

>                                      MEMORANDUM

>                                                         February 28, 1997

>          BY FACSIMILE

>          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,

>          Enclosure

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

> [nscp-1]

> ## "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.)

> Introduction

> 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

> [nscp-2]

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

> [nscp-3]

> 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:

> - Program the clients (and servers) in an Intranet to only trust certain CAs for issuing certificates and certain locations for providing key escrow functions. these features can be restricted by a company, country or any other useful domain.

> - Program the clients (and servers) to only submit certificate requests to certain locations. This gives Intranets control over the ownership of the clients' private keys.

> [nscp-4]

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

> [nscp-5]

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

> [nscp-6]

> ###

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

> - Escrow Flag indicating that the key is a key exchange or encryption key and is escrowed using the X.509 extension mechanism.

> - URL for the entity that performed the escrow can be the same as the CA or different, the URL may represent multiple parties that have to cooperate to produce the keys if an M out of N scheme for storing the private keys.

> - Some indication of the Intranet affiliation. This field may be used by some countries to verify the location of the escrow.

> ###

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

> [nscp-7]

> ###

> 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:

> - In the majority of the cases, an SSL session allows clients access to data on a server. SSL session keys are not necessary to access encrypted data.

> - Controlling sales of SSL-enabled servers to countries and companies that are established as "good citizens" will restrict clients' access to servers with strong cryptographic support.

> - Some restrictions on the Certification Authorities allowed to be trusted by the client may be necessary to enforce this policy.

> - In this model, the availability of the data on the server obviates the need for inline decryption during transmission, if recovery of the data is needed.

> ###

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

> [nscp-8]

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

> [nscp-9]

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

> [nscp-10]

> ###

> 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)
> |  | Version |
> |  | 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.]

> [nscp-11]

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

> | Application #2 (e.g. S/MIME)
> |  | Version |
> |  | 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)
> |  | Version |
> |  | 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

> [nscp-12]

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

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

> > > SSL2-RC4-128-WITH-MD5=true

> > > SSL2-RC4-128EXPORT40-WITH-MD5=true

> > > SSL2-RC2-128-CBC-WITH-MD5=true

> > > SSL2-RC2-128-CBC-EXPORT40-WITH-MD5=true

> > > SSL2-DES-64-CBC-WITH-MD5=true

> > > SSL2-DES-192-EDE3-CBC-WITH-MD5=true

> > > SSL3-RSA-WITH-NULL-MD5=true

> > > SSL3-RSA-WITH-RC4-128-MD5=true

> > > SSL3-RSA-WITH-3DES-EDE-CBC-SHA=true

> > > SSL3-RSA-WITH-DES-CBC-SHA=true

> > > SSL3-RSA-WITH-RC4-40-MD5=true

> > > SSL3-RSA-WITH-RC2-CBC-40-MD5=true

> > > SSL3-FORTEZZA-DMA-WITH-FORTEZZA-CBC-SHA=true

> > > SSL3-FORTEZZA-DMS-WITH-RC4-128-SHA=true

> > > SSL3-FORTEZZA-DMS-WITH-NULL-SHA=true

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

> [nscp-13]

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

> - The manufacturer of the CSP signs the code implementing the CSP or the driver to the CSP hardware. This is done to ensure integrity of the CSP. There is no guarantee here for the CSP vendor obtaining export license. Rather, the Netscape product itself will monitor the combination of the CSP with Netscape products as described above so that the CSP provides the cryptographic support allowed by the export laws of the various countries.

> - Each application in the Netscape product determines the key length allowed from the configuration file under that application after verifying the Netscape signature on the CCM.

> - The application code filters the requests from the application to the CSP to provide the appropriate key length, even if the CSP supports higher grade encryption.

> - When the CSP first attaches to the Netscape software, a check is made on the encryption routines supported by comparing the output of encrypting a test vector with the correct output for that algorithm. This mechanism is so the CSP does not advertise the "DES" capability, for example with a rogue implementation that attempts to avoid export laws.

> [nscp-14]

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

> >     [Stamp]

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

[End]

Transcription and HTML by JYA/Urban Deadline