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

Newsgroup: mozilla.dev.tech.crypto
Draft Version 0.8.1, 15 September 2001

Introduction

In July 2001 we made an interim NSS 3.3 release that only implemented some of the features originally planned for NSS 3.3.

The goal of NSS 3.4 is to finish the remaining features originally planned for NSS 3.3 and the features required by NSS clients shipping in Q1 2002.  The features include the implementation of the core cert functionality of NSS 4.0 (code name Stan), a new SSL server session ID cache, and S/MIME v3 support.  We will also continue the SSL performance enhancement work.

Features

In

  1. S/MIME v3.  Netscape 6.x will support S/MIME soon.  Our S/MIME code needs more code review, testing, enhancement, and documentation.  It needs to interoperate with Netscape Communicator, Microsoft Outlook Express, and Netscape 6.x (when implemented).
  2. A new function SSL_GetChannelInfo() that addresses the inadequacies of the SSL_SecurityStatus() function.  This new function should report all the information that Microsoft Internet Explorer reports on an SSL channel.  Publish Nelson's API proposal. (PSM bug 78837 depends on this.)
  3. Put together a list of cert handling problems that need to be fixed (some have been filed in Bugzilla and some are described in Bob Lord's Certificate/Key Storage Requirments document).  Review NSS 4.0's cert architecture to verify that it addresses these problems.
  4. Implement enough NSS 4.0 cert functionality to alleviate the problems caused by the inability to treat certs from PKCS #11 modules the same as  certs from the cert database.
    • Move the current cert database code under PKCS #11.
    • Implement the higher level cert cache and searching code using Stan opaque data structures.
    • Emulate the exported cert database access functions using the low level Stan functions.  If any of the exported functions can't be emulated, we should publish the list of the exported functions that will go away in NSS 3.4 immediately.
    • Provide new utility functions to convert NSSCertificates into CERTCertificates.
    • Provide new Stan functions that will allow applications to get around some of the problems with multiple sources for the same cert.
  5. SSL server session cache.  Use shared memory and reduce hash collision.
  6. Implement the TLS AES ciphersuites. Need to interoperate with another implementation of TLS AES ciphersuites. Note: the server-side code of the TLS AES ciphersuites using Diffe-Hellman Ephemeral (DHE) for key agreement will not be implemented.
  7. A new function to add a certificate to a specified token.
  8. NSS should be able to import a large number of wrapped keys temporarily and use the keys in S/MIME functions. We should write a test to verify that we can do this with existing NSS functions or to find out what functions are missing.
  9. Automatic failover from hardware to software crypto token if hardware accelerators fail.  This only works if the keys are in both the hardware and software tokens.  It is a concern that the automatic failover may mask bugs in NSS.
  10. PKCS #11 library database format.  Design and implement a common file format that all crypto libraries and applications can use to determine which PKCS #11 libraries they need to load, and propose it to the PKCS #11 Work Group.
  11. DBM 1.5.6 should use source code on mozilla.org and use NSPR 4.1.2.

Out

  1. OCSP HTTP client may potentially block for a long time.  Possible solutions include a configurable timeout or a callback supplied by the NSS client.
  2. Multiple trust domains for virtual servers.
  3. Better error reporting, for example with an error stack.
  4. Release the regress tool, which is required by the Netscape PKCS #11 test suites.
  5. Conform to latest PKCS #11 revision (2.11).
  6. Notification of hardware accelerator failures.
  7. Tools: review and implement signtool enhancement requests (Bugzilla bugs #66600, #66603, #66604, #66606, and #66608).
  8. CMC support.
  9. Tools: dbck should work.
  10. AES support in S/MIME.
  11. Interpretation of the CRL nextUpdate timestamp.
  12. Conform to RFC 2459.
  13. OCSP reliability.
  14. Cross certification.
  15. Elliptic Curve Cryptography (ECC).
  16. XML Key Management Specification (XKMS).
  17. OCSP local caching.
  18. Multiple client applications share the same cert and key databases.
  19. Enable PSM to use NSS shared libraries.
  20. Resolve the remaining build issues with Mozilla client. Allow compilers (CC, CXX) and tools (PERL, ZIP) to be overridden. (Bug #52990)
  21. Combine SVRCORE with NSS.
    • move the useful SVRCORE functions to NSS; or
    • help LDAP C SDK replace SVRCORE with existing public NSS functions.
  22. NSS should process UTF-8 strings correctly.  For example, when a web server constructs a certificate request, it passes UTF-8 to NSS and NSS converts UTF-8 to UCS4 for ASN.1 Universal String encoding.
  23. NSS should support certificate nicknames in multibyte character sets.
  24. Anything that uses certificates or refers to certificates (for example, CRLs) should be able to use Distinguished Names (organization name, common name, etc.) in multibyte character sets.  This applies to not only the C API functions but also the command-line tools such as certutil.
  25. Command-line tools such as certutil should support the default character set of the locale, which is often not UTF-8.
  26. NSS should use NSPR's error message functions for its error messages.
  27. NSS should support UTF-8 in certificate extensions.
  28. CERT_NameToAscii() should return the certificate attributes in UTF-8.
  29. The name of the built-in internal token is hardcoded and cannot be localized.

Performance Enhancement

In

  1. Instrument 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.
  2. Reduce lock contention.
  3. Set the TCP_NODELAY socket option when appropriate in the SSL protocol.

Out

  1. Coalesce small reads in SSL.

Bugs

The complete list of bugs that will be fixed in NSS 3.4 can be found in Bugzilla.  We will assign high priority to the database corruption bugs.

Components

  • NSPR 4.1.2.
  • DBM 1.5.6.

    • Platforms Supported

    NSS is maintained on the platforms listed below. "Certify" means the 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
    4.3.3    		 xlC/C++ 3.6.6
    4.3.3 (64 bit) 4.3.3 xlC/C++ 3.6.6
    Compaq Tru64 5.0A 5.0A 
    5.1    		 (cc) Digital C v5.6-071
    HP-UX 11.0 (32 bit) 11.0 C compiler: A.11.01.00
    11.0 (64 bit) 11.0 C compiler A.11.01.00
    Linux 2.2 Red Hat 6.0 Red Hat 6.2 egcs-1.1.2
    GNU ld version 2.9.5 (with libbfd-2.9.5.0.22.so)
    Linux 2.4 Red Hat 7.1 Red Hat 7.1 gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)
    NT NT 4.0 w/ SP 6a NT 4.0 w/ SP 6a 
    Win2000 w/ SP 2    		 VC++ 6.0 Service Pack 4
    Windows NT 4.0 w/ SP 6a NT 4.0 w/ SP 6a 
    Win2000 w/ SP 2

    Win95 OSR2 * 
    Win98 SE * 
    Win Me *

    		 VC++ 6.0 Service Pack 4
    Solaris SPARC 2.6 2.6 WorkShop Compilers 
    C/C++ version 5.0
    8 (32 bit) 8 (32 bit)
    8 (64 bit)
    9    		 Forte 6 update 2
    8 (64 bit) 8
    9    		 Forte 6 update 2
    Solaris x86 8 8
    9    		 Forte 6 update 2
    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 regarding 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.

    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.
     
    Milestone Date
    PRD approved Fri. 09/07/01
    Feature complete Mon. 10/22/01
    Beta Mon. 10/29/01
    Certification (RTM Candidate) Mon. 11/12/01
    RTM Fri. 11/16/01