FIPS Design Assurance
Configuration Management
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.
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, softokn3 and freebl3, 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 of 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 periods of operation. The following rules should be adhered to.
- Physical security of the computer and peripherals must be maintained.
- Access to the files and directories where NSS is installed must restricted to the Crypto officer via the access mechanisms of the host operating system.
- Access to the memory space of the running crypto application must be secure from snooping.
- Certificate data base passwords must be secured.
- Private key material that is imported to or exported from the crypto module, e.g. in PKCS #12 files, must be encrypted and the passwords protected.
There is no proprietary guidance for the NSS crypto module.