You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

History of NSS

Newsgroup: mozilla.dev.tech.crypto
Technical contact: Bob Relyea
Yell at the manager: Bob Lord

This document provides an informal history of Network Security Services based on the recollections of some of the engineers involved.

Network Security Services started out as the base security code used by the original Netscape Navigator products. In the beginning, this code was packaged and built as part of the monlithic client, as follows:

  • Navigator 1.0. The first version of the security code supported SSL 2.0 only.
  • Navigator 2.0. Support for SSL 3.0 was added, changes were made to the certificate-handling code, and the certificate database file was rev'd to version 4.0. At about this time the security code was also copied for use in the Netscape 2.0 servers. Before their release, support for private keys (necessary for server side SSL) was added to the base code.
  • Navigator 3.0. Support for client authentication, which required the client to support private keys, was added to the base code in Navigator 3.0. The certificate database file was also rev'd to version 5 (cert5.db), and a new key db file was added. This code, with some modifications, became the basis for the security capabilities of the SuiteSpot servers (version 3).
  • Communicator 4.0. The security code was partially broken out into its own component, with most of the code dependent only on NSPR and the database code. Only the client UI portion was dependent on the main part of the client code. In addition to SSL 3.0 and client authentication, Communicator 4.0 supported S/MIME (signed and encrypted email), PKCS #11 (loadable crypto modules and smart card support), PKCS #12 (import and export of private keys and certificates), object signing, multiple certificates for the same subject, and PKIX types, among other things. This release also saw major changes to the certificate-handling library. The certificate database was rev'd to version 7 (cert7.db) and the key database to version 3 (key3.db).
Soon after the release of Communicator 4.0, the security code began to be released independently of the client and server products. These are the major releases since that time:
  • HCL 1.0 through 1.57. HCL ("Hard Core Library") 1.0 was the first release of the security code that could build independently of the client or the server. HCL 1.5 was the first version released internally as a binary only distribution. Many of the 4.0 servers were prototyped using HCL 1.57, which was later released as NSS 1.0 to some select customers.
  • NSS 2.0 through NSS 2.7. NSS 2.0 was the first release that was fully tested and made available outside of Netscape. Major enhancements in version 2.0 included documentation and cleanup of the SSL APIs. Many of the other internal APIs, which were designed ad hoc and primarily to support the Communicator 4.0 features, were not evaluated or exposed to external customers. NSS 2.x also added features such as OCSP, fixes and updates to dual key support, Software FORTEZZA support, SSL performance enhancements, and CRMF and CMMF support. NSS 2.1, 2.6, and 2.7 are the primary versions driving the iPlanet 4.0 servers. They are also the basis for Netscape Personal Security Manager (which provides security for the Mozilla client) and a number of third-party party software products.
The initial NSS source code package for Mozilla includes most of NSS 2.7, the TLS code for NSS 2.8, and a first look at the new NSS 4.0 APIs. We are in the process of completing the initial design phase for NSS 4.0. Primary design goals for NSS 4.0 include the following:
  • Cleaner support for querying certificates to PKCS #11 (for example, to allow PKCS #11 modules to supply certificates from LDAP).
  • Better handling of corner cases in the certificate code.
  • Consistent APIs throughout the toolkit.
  • Better documentation of some of the non-SSL APIs of interest to developers.
  • Better error diagnostics, permitting applications to present more meaningful error messages to the user and programers to gain better understanding of what may have gone wrong with their programs.
  • Simplify the initialization needed to complete certain tasks.
For information about the architecture of NSS 2.x, see Introduction to Network Security Services.