FIPS Design Assurance

Configuration Management

Configuration Management System

NSS is maintained according to the development standards and rules of the Mozilla Foundation. The CVS version control system is used for maintaining all changes to the source files of NSS. NSS source files are contained within four directories within the mozilla.org CVS repository. Each file is tracked with a revision number and a complete change history is maintained. Releases are given a CVS tag when the release is published. A source file is uniquely identified by its fully qualified pathname within the source tree and the revision number or CVS tag. NSS source includes all makefiles and scripts used to create the NSS release on every platform supported.

NSS Documentation is published on www.mozilla.org, wiki.mozilla.org, and developer.mozilla.org. www.mozilla.org is maintained by CVS. wiki.mozilla.org and developer.mozilla.org are maintained by wiki. The wiki keeps a history of changes by time stamp for each wiki page and image.

NSS uses Bugzilla (https://bugzilla.mozilla.org/) for bug tracking. Bugzilla tracks not only bugs but also enhancement requests and dependencies.

Configuration List

The configuration items are:

• cryptographic module: the module has the same version as the module components. See the next item.
• software module components: the libsoftokn3 and libfreebl3 libraries are uniquely identified by their file names. On Unix, their versions can be uniquely identified by the what or ident command, for example, "what libsoftokn3.so | grep NSS" and "ident libfreebl3.so | grep NSS". On Windows, their versions can be uniquely identified by the Version tab in the Properties dialog.
• security policy (including user guidance): the security policy is uniquely identified by its URL, and its version is uniquely identified by the "last modified" time stamp at the bottom of the security policy.
• operating system: see the operating system documentation for the methods used to uniquely identify the operating system and its version. (On Unix, use the "uname -a" command. On Windows, use the System applet in the Control Panel.)
• associated module documentation: each documentation page is uniquely identified by its URL, and its version is uniquely identified by the "last modified" time stamp at the bottom of the page.

Installation

NSS releases are available from mozilla.org's FTP site as compressed (gzipped) tar files or zip files. The tar or zip file is expanded into a file system directory in a location that is suitably secured using the capabilities of the local operating system.

Typically, at this point, an application is configured to use NSS libraries from this directory. Such configuration consists of the following steps, which can also be performed with NSS command line utilities.

• Initialize the certificate and private key databases.

• Import the certificates and private keys that are to be used by the application into the databases.

• Put the NSS cryptographic module into FIPS mode. See Approved Mode of Operation and Security Policy Rule #36 for information on accomplishing this programatically and via command line utilities.

Components

All software components of the NSS cryptographic module are contained within two libraries, libsoftokn3 and libfreebl3, as described in Section 1. The combined role that is supported is realized entirely within these two libraries. Each of these libraries is shipped with a checksum file containing a DSA signature of the library file. When NSS is started up in FIPS mode, the module recomputes the SHA-1 hash of the library file and verifies the signature. Initialization fails if the signature is not valid.

An annotated source listing of the software components contained in the NSS cryptographic module is here.

The hardware components contained in the NSS cryptographic module are the hardware components of a general purpose computer.

Functions

After installation and setup the Crypto Officer must ensure the integrity of the cryptographic module during normal operation. The following rules should be adhered to.

1. Physical security of the computer and peripherals must be maintained.
2. Write access to the files and directories where NSS is installed must be restricted to the Crypto Officer via the access control mechanisms of the host operating system.
3. Access to the memory space of the running crypto application must be secure from snooping.
4. Private key database passwords must be secured.
5. Private key material that is imported to or exported from the cryptographic module, e.g., in PKCS #12 files, must be encrypted and the passwords protected.

The crypto officer and user nonproprietary guidance for the NSS cryptographic module is part of the Security Policy.