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

Newsgroup: mozilla.dev.tech.crypto
Engineering lead: Bob Relyea
Product Manager: Roland Jones
Engineering manager: Wan-Teh Chang

Draft Version: 0.1.3

Introduction

Earlier 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. To build NSS 3.0 requires a licensed copy of RSA's BSAFE Crypto-C Library to provide low-level crypto functionality.

The main goal of NSS 3.1 is to have a complete open-source implementation of the NSS crypto libraries. A second goal is to establish a framework to which developers and OEMs can contribute patches, such as assembler code, to optimize performance on their platforms.

Features and Tasks

  • NSPR 4.1 support (dual MPL/GPL license; beta 8/11, RTM candidate 8/25, RTM 9/1).
  • DES
  • BigNum package based on MPI: Arbitrary Precision Integer Arithmetic.
  • Unencumbered crypto code on top of the BigNum package, including RSA public key, RSA private Key, Diffie-Hellman, Fortezza KEA, DSA sign, DSA verify, key generation, param generation and verification, and other algorithms. Work related to the RSA algorithms will begin on 9/21.
  • A FIPS-compliant pseudo-random number generator
  • An arcfour implementation
  • Root CAs
    • Checked into the cvs server at mozilla.org.  Each vendor has a separate directory.
    • Versioning of root CAs.
    • Root CAs tied to applications, not NSS.
  • S/MIME Toolkit
  • Measure the performance of NSS 3.1
  • Build system: simplify build procedure
  • Document possible plans for releasing NSS as shared libraries/DLLs
Bugs Fixed
  • TBD

Release Focus

  • Mozilla developers

Platforms Supported

  • NSS team builds, certifies, and supports the following platforms.
Platform Build Certify Compiler(s)
AIX 4.3.3 (32 bit) 4.3.3 xlC/C++ 3.6.4
4.3.3 (64 bit) 4.3.3 xlC/C++ 3.6.4
Compaq Tru64 4.0D 4.0D 
5.0A		 (cc) Digital C v5.6-071
HP-UX 11.0 (32 bit) 11.0 (32 bit) C compiler: A.11.01.00
11.0 (64 bit) 11.0 (64 bit) C compiler: A.11.00.00
Linux RedHat 6.0 RedHat 6.0, 6.1, 6.2 egcs-1.1.2
Macintosh 8.5  8.5 
9.x		 Metrowerks 
CodeWarrior
NT NT 4.0 w/ SP 6a NT 4.0 w/ SP 6a
Win2000		 VC++ 6.0 Service Pack 3
Windows NT 4.0 w/ SP 6a 95 OSR2
98 SE
NT 4.0 w/ SP 6a
Win2000		 VC++ 6.0 Service Pack 3
Solaris 2.6 2.6 and 8 (32-bit and 64-bit) WorkShop Compilers 
C/C++ version 4.2 
8 (64-bit) 8 (64-bit) WorkShop Compilers 
C/C++ version 5.0

Doc Plan

Preliminary documentation for the S/MIME Toolkit API will be added to the NSS Reference Documentation.

Schedule

Task Date
BigNum package integrated, without performance tuning 7/28
Feature cut-off 8/4
Beta 9/11
Certification (RTM Candidate) 10/6
RTM 10/13

Root Cert Plan

We need to change the way we handle updating root certs to meet the following new goals:
  • Be able to include the certs in the source tree.
  • Allow vendors to replace our set of root certs with their own without conflicting between their application and ours.
  • Allow field upgrade of the root certs without building a new version of the NSS libraries or new versions of the applications that use the libraries.
    • We discussed three possible solutions to the problems of multiple applications defining their own list of trusted roots.

    Here is the summary of those solutions.

    Option 1

      Use the existing root cert update structure, making the list of cert a dll, each application would maintain their own copy of the database.

      Advantages:

    • Relatively simple to implement.
      • Disadvantages:
    • Applications would not be able to share key and cert material.
    • Unless additional code is added to protect one application's DB from another, the chances of unrecoverable corruption because an application started with a wrong database is high.

    Option 2

      Use the existing root cert update structure, making the list of cert a dll, and keep a separte internal DB version number for each application.

      Advantages:

    • Also relatively simple to implement.
      • Disadvantages:
    • This changes the database format. It may be possible to keep the DB major version number so old applications can recognize the DB.
    • We would have to manage an id space for each application.
    • There is still potential for applications stomping on each other's trust changes -- particularly if they use the same root cert.

    Option 3

      Go to a Stan-like structure. ("Stan" is the working name for NSS 4.0, which will include a new, multi-process-safe cert database and a dynamically loadable cert/key store.) Implement enough of Stan to load an internal DB (potentially internal) and "internal" RO trust DB (external).

      Advantages:

    • We can support all our existing semantic, plus many new ones.
    • It takes us down the first step toward stan-like Certificate structure.
    • It splits trust from the key and cert DBs.
      • Disadvantages:
    • It's a lot more complicated than the other proposals.

    Option 3: Implementation

    In fleshing out option 3, we need to decide how to implement it and what can we do to reduce the risks involved.

    First we should assume minimal changes to the PKCS #11 loading code. Rather than including the whole Stan infrastructure for loading PKCS #11 modules, we can simply use the existing structure, with code that can help 'discover' the applications trusted root cert base.

    We also don't need to implement the Stan wrapped key semantics for this to work.

    We will have to introduce the new Stan trust module, at least for a single trust domain. We only need enought to implement it under the existing API.

    The basic design would be to have the root certs live in a read-only 'Database'. This DB would be accessed through a separate PKCS #11 module. The cert code would be modified to only search for certificates through PKCS #11, and not through the cert DB code.

    Trust will include both accept and reject versions of trust. Trust would be merged through a heiarchy of trusted modules.

    Certificate verification would have to be modified to support this trust information.

    • Step 1. Modify the Hi cert code to always use PCKS #11 and it's own local cache to search for certificates. This will involve designing and implementing at least a simple cert caching scheme.
    • Step 2. Modify the internal PKCS #11 module to export all the certificates, not just the user certificates.
    • Step 3. Modify the Trust parsing code to handle multiple sources of trust.
    • Step 4. Add code the the PKCS #11 load modules to load the RO version of the database.

    Issues that need to be addressed:

    • How do you 'discover' the PKCS #11 static load module if one isn't already loaded.
    • Need to understand how much of the cert code has to change.

    Useful links