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
|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|
|(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|
|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||95 OSR2
NT 4.0 w/ SP 6a
|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
|BigNum package integrated, without performance tuning||7/28|
|Certification (RTM Candidate)||10/6|
We discussed three possible solutions to the problems of multiple applications defining their own list of trusted roots.
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.
- Relatively simple to implement.
- 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.
- Also relatively simple to implement.
- 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.
- 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.
- It's a lot more complicated than the other proposals.
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.
Issues that need to be addressed: