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

NSS 3.3 Plan

Newsgroup: mozilla.dev.tech.crypto
Engineering lead: Bob Relyea
Product manager: Roland Jones
Engineering manager: Wan-Teh Chang
Draft Version 0.4, 1 Mar. 2001

Introduction

In February 2001 we released NSS 3.2. For the first time, this release provides NSS in the form of shared libraries, which make it significantly easier for us to deliver bug fixes and performance enhancements to our customers. Performance of RSA operations also improved substantially on several platforms in NSS 3.2.

One issue we did not have time to address in NSS 3.2 was to enable JSS to use the NSS shared libraries. (JSS uses some private NSS functions that we do not want to export from the NSS shared libraries). This forces JSS to link in NSS static libraries. As a result, it is not practical to use JSS in a process that is already linked with NSS, since the process will have two copies of NSS.

The main goal of NSS 3.3 is to enable the use of NSS shared libraries by JSS. Other important goals are to implement the core certificate architecture of NSS 4.0 (code name Stan) and continue to enhance SSL performance.

Features and Tasks

NSS 3.3 has the following goals.

P1: Must Have

  1. Enable JSS to use the NSS shared libraries. We need six weeks to finish this work. Target Milestone 1. (relyea, nicolson)
  2. Put together a list of cert handling problems that need to be fixed (some have been filed in Bugzilla) and review NSS 4.0's cert architecture to verify that it addresses these problems. (relyea, mcgreer)
  3. Implement the core cert architecture of NSS 4.0. (relyea)
    • Improve the robustness of handling certs in the cert database and PKCS #11 modules.
    • PKCS #11 interface to the DBM module.
  4. Design and implement a method to store and load PKCS #11 modules on all platforms, such as in the registry or in a directory server, and propose it to the PKCS #11 Work Group.  Use this method to turn secmod.db into a PKCS #11 module. (relyea)
  5. Performance: SSL server session cache.  Use shared memory and reduce hash collision. (nelsonb)
  6. Performance: lock contention. (kirke, larryh)
  7. Performance: memory allocation.  Reduce the contention on the heap lock.  Ideally our clients should not need to use a specialized malloc package like SmartHeap. Possible solutions include free lists for frequently used data structures, zone allocators, and per-thread arena pools. (kirke)
  8. Performance: set the TCP_NODELAY socket option when appropriate in the SSL protocol. (nelsonb)
  9. AES support in TLS. (nelsonb)
  10. Merge Dr. Henson's contributions to NSS. (nelsonb)
  11. Update the list of encryption technologies and file a new CCR for NSS 3.3 as it will have AES and other new encryption technologies. (relyea, wtc)

P2: Highly Desirable

  1. Conform to latest PKCS #11 revision (2.11). (relyea)
  2. Tools: review and implement signtool enhancement requests (Bugzilla bugs #66600, #66603, #66604, #66606, and #66608). (relyea)
  3. Resolve the build issues with Mozilla client. Add an autoconf-like configure script that does not require fundamental changes to the NSS build system. (Bug #52990) (relyea, wtc)
  4. Combine SVRCORE with NSS. (relyea)
    • move the useful SVRCORE functions to NSS; or
    • help LDAP C SDK replace SVRCORE with existing public NSS functions.
  5. Enable PSM to use NSS shared libraries. (relyea, javi)
  6. CMC support. (javi or nelsonb)
  7. Tools: dbck should work. (mcgreer)
  8. AES support in S/MIME. (nelsonb, mcgreer, chrisk)

P3: Nice to Have

  1. Performance: coalesce small reads in SSL. (kirke)
  2. Elliptic Curve Cryptography (ECC). (unassigned)

International Requirements

TO DO.

Platforms Supported

NSS is maintained on the platforms listed below. "Certify" means the iPlanet NSS team will build and run QA tests for NSS on a machine with the specified OS.
 
Platform Build Certify Compiler(s)
AIX 4.3.3 (32 bit) 4.3.3 (32 bit) 
4.3.3 (64 bit)		 xlC/C++ 3.6.6
4.3.3 (64 bit) 4.3.3 (64 bit) xlC/C++ 3.6.6
Compaq Tru64 4.0D 4.0D 
5.0A		 (cc) Digital C v5.6-071
HP-UX 11.0 (32 bit) 11.0 (32 bit) 
11.0 (64 bit)		 C compiler: A.11.01.00
11.0 (64 bit) 11.0 (64 bit) C compiler A.11.01.00
Linux Red Hat 6.0 Red Hat 6.1 
Red Hat 6.2		 egcs-1.1.2
NT NT 4.0 w/ SP 6a NT 4.0 w/ SP 6a 
Win2000		 VC++ 6.0 Service Pack 4
Windows NT 4.0 w/ SP 6a NT 4.0 w/ SP 6a 
Win2000 
Win95 OSR2 * 
Win98 SE * 
Win Me *		 VC++ 6.0 Service Pack 4
Solaris 2.6 2.6 
8 (32 bit) 
8 (64 bit)		 WorkShop Compilers 
C/C++ version 5.0
8 (64 bit) 8 (64 bit) WorkShop Compilers 
C/C++ version 5.0
IRIX 6.5 6.5 ** MIPSPro 7.3
Mac OS 9 8.5 * 
8.6 * 
9 *		 Metrowerks CodeWarrior Pro 5

* Full QA certification will not be done on these platforms. We will only verify that PSM built with NSS 3.3 works on these platforms.

** Optional.

NSS has not yet been formally certified on any other platforms. If you have successfully run NSS QA tests on other platforms, please post the test output logs and results to mozilla.dev.tech.crypto. If you are interested in taking responsibility for testing and maintaining NSS on a particular platform that's not listed above, post a message to mozilla.dev.tech.crypto.

Note re NT builds: The build listed in the left column above as the "NT" build will run on NT (including Windows 2000) only and hence can potentially take advantage of some Win32 functions that are only implemented on NT, such as fibers and I/O completion ports. The build listed above as the "Windows" build will run on all Windows flavors -- 95, 98, Me, NT, and 2000.

Only NSPR makes use of this NT vs. Windows distinction and provides different NT and Windows builds. Many Netscape products, including NSS, have NT and Windows builds that are essentially the same except one difference: one is linked with the NT version of NSPR and the other is linked with the Windows version of NSPR.

QA Test Plan

  1. Restructure the QA test scripts and rewrite portions of them to improve speed and readability. (sonmi)
  2. Clean up some tests such as tstclnt and strsclnt. (sonmi)
  3. Test the loadable root certs module. (mcgreer)
  4. Check the version identification strings in the shared libraries. (sonmi)
  5. Measure the test coverage. (sonmi)
  6. Test shared library backward compatibility against NSS 3.2. (sonmi)
  7. Improve the tools tests. (sonmi)
  8. Test NSS on hardware accelerators such as Chrysalis, nCipher, and Rainbow. (sonmi. relyea, nelsonb, and javi to install the hardware and drivers.)
  9. Make our QA test scripts run under the Cygwin tools as well as MKS Toolkit on Windows. (sonmi)
  10. Improve the readability of the output log of our tests. (sonmi)

Documentation Plan

At a minimum, all the NSS public functions should be documented.  The NSS engineers will use an HTML template provided by our technical writer to document the functions in a consistent style.  We should also document the S/MIME library in the same way the SSL library is documented in the SSL Reference, with overviews, tutorials, and sample code.  (The API of the NSS base library is going to change in NSS 4.0, so we are not planning to do a comprehensive documentation of it at this moment.)

Schedule

We have the following target dates.  Feature development will proceed in three milestones to stay responsive to unexpected or changing requirements.  At each milestone NSS should be in a good and stable state so that it can be easily turned into a release if necessary (for example, to enable JSS to use NSS shared libraries sooner).
 
Task Date
Feature list frozen 3/2/01
Milestone 1 4/27/01
Milestone 2 6/29/01
Milestone 3: feature complete 8/31/01
Beta 9/7/01
Certification (RTM Candidate) 9/24/01
RTM 9/28/01