NSS 3.2 Plan
Engineering lead: Bob Relyea
Product Manager: Roland Jones
Engineering manager: Wan-Teh Chang
IntroductionEarlier this year, we contributed NSS to the open source community. All the code that we could publish was released as NSS 3.0 on mozilla.org. In October of 2000, we released NSS 3.1, a complete version of NSS that included support for the RSA algorithm. A major drawback of NSS 3.1 was that it did not perform as well as NSS 2.83 on some hardware platforms.
Note: NSS 3.1 really comes in three flavors. The first uses a library called libcrypto to perform many low-level crypto functions. (We cannot release the source code for libcrypto because it is based on proprietary source code licensed from RSA Security.) The second uses the standard BSAFE Crypto-C library from RSA Security. The third uses the open source NSS freebl routines. In this document, the term "NSS 3.1" means "NSS 3.1 with freebl"; in other words the completely open-source flavor.
The main goal of NSS 3.2 is to provide equal (or better) performance compared to NSS 3.1 with libcrypto, which we believe performs much like NSS 2.83 on the major hardware platforms. Other goals are listed below.
Features and Tasks
NSS 3.2 has the following goals:
- SSL performance.
- As fast as NSS 3.1/libcrypto: NSS 3.2 will have performance comparable to NSS 3.1/libcrypto, which we believe has performance comparable to NSS 2.83. The modular exponentiation, symmetric crypto operations, and hashes in NSS 3.1/freebl are already as fast as NSS 3.1/libcrypto on SPARC and Intel architectures. We want to achieve this parity on all platforms in 3.2 and support only the pure open source "freebl" flavor of NSS. (NSS 3.2 users can continue to plug in their licensed copies of BSAFE Crypto-C, but the iPlanet team will not officially support that model.) We will produce a document that shows NSS 3.1/libcrypto performance on all our major platforms, as well as NSS 3.2 performance.
- Apples-to-apples Measurements: Different hardware platforms perform the math operations required for SSL at different rates. We'll produce a document that shows how well one platform stacks up against another.
- Instrumentation: We will produce a document that describes our plan to measure and research NSS performance, in particular lock contention and multiprocessor scalability.
- Shared library/DLL support. This is the feature that everybody wants and will make it significantly easier for us to deliver a bug fix or version upgrade.
- On Sep. 29 we submitted the Commodity Classification Request for NSS retail status to BXA. We have received the retail status confirmation, which allows us to release NSS as shared libraries/DLLs.
- The conversion to shared libraries implies that NSS will need to maintain binary compatibility. We will review, clean up, and document the NSS API and commit to it in NSS 3.2. As a result of the shared library support, NSS users will need to modify the linking commands in their makefiles. It may also be necessary to make source code changes because of the API cleanup but we will try very hard to minimize that.
- We will also need to embed version information in the shared libraries that installers can retrieve. We are soliciting suggestions on how to do that on all the platforms.
- We will release binaries of NSS shared libraries and utility tools on mozilla.org.
- Note: due to the lack of Mac OS expertise, shared library support on Mac OS is not required in this release.
- We will measure our test coverage on Solaris and Windows NT.
- We will improve our test coverage in the ciphers, S/MIME, and tools areas.
- We will enhance our tests to collect key performance metrics in addition to validating functional correctness.
- We will run automated QA on our nightly builds.
- We will study and understand the iPlanet internationalization testing requirements.
- AES has not yet become a FIPS. It is expected to do that next year. By the time it does, it is also expected that SHA1-256 (SHA1 with a 256-bit hash output) will also be a FIPS, and that various standards will also require the use of SHA1-256 with AES.
- Because of our total dependence on PKCS#11, we cannot use AES or SHA1-256 in our code (e.g. in SSL or PKCS#7) until the PKCS#11 group defines the necessary PKCS#11 "mechanisms" for those algorithms.
Platforms SupportedNSS 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.
|AIX||4.3.3 (32 bit)||4.3.3 (32 bit)
4.3.3 (64 bit)
|4.3.3 (64 bit)||4.3.3 (64 bit)||xlC/C++ 3.6.4|
|(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
|NT||NT 4.0 w/ SP 6a||NT 4.0 w/ SP 6a
|VC++ 6.0 Service Pack 3|
|Windows||NT 4.0 w/ SP 6a||NT 4.0 w/ SP 6a
Win95 OSR2 *
Win98 SE *
Win Me *
|VC++ 6.0 Service Pack 3|
8 (32 bit)
8 (64 bit)
C/C++ version 4.2
|8 (64 bit)||8 (64 bit)||WorkShop Compilers
C/C++ version 5.0
|Mac OS||9||8.5 *
|Metrowerks CodeWarrior Pro 5|
NSS has not yet been formally tested or certified on any other platforms. If you have successfully run NSS on other platforms, or 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.
* Full QA certification will not be done on these platforms. We will only verify that PSM built with NSS 3.2 works on these platforms.
Doc PlanA complete list of supported and deprecated functions will be added to the NSS Reference Documentation, and Introduction to Network Security Services will be updated to reflect the new set of libraries. A migration guide will be added to help users of previous NSS releases to upgrade to NSS 3.2.
ScheduleWe have the following target dates, however this release will be performance driven.
|Feature list frozen||11/17/00|
|Certification (RTM Candidate)||1/24/01|