Introduction

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

• TBD

Release Focus

• Mozilla developers

Platforms Supported

• NSS team builds, certifies, and supports the following platforms.

Doc Plan

Schedule

Root Cert Plan

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.

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

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

• NSS project page
• NSS reference documentation