NSS

Network Security Services

Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. For detailed information on standards supported, see Overview of NSS.

NSS is available under the Mozilla Public License, the GNU General Public License, and the GNU Lesser General Public License. For information on downloading NSS releases as tar files, see Download PKI Source.

Mozilla NSS documentation can be found at [1]. NSS is undergoing it's third round of FIPS Validation.

PKCS #11 Module Specs

The following is a proposal to the PKCS #11 working group made in August 2001 for configuring PKCS #11 modules. NSS currently implements this proposal internally.

The file format consists of name/value pairs of the form name=value. Each name/value pair is separated by a blank value. A single line, terminated by a '\n', '\r\n', or '\r' represents a single pkcs #11 library.

Names can be any alpha/numeric combination, and are parsed case-insensitive.

Values can contain any printable ascii value, including UTF8 characters. Values can contain imbedded blanks either through quoting the entire value, or by escaping the imbedded blanks with '\'. The value is considered quoted if the first character after the '=' is ', ", {, [, (, or <. If the value is quoted, then the value is terminated with and ending quote of the form ', ", ), ], }, or > matching the respective starting quote. Ending quotes can be escaped. Imbedded '\' charaters are considered escape characters for the next character in the stream. Note that case must be preserved in the values.

Recognized Names:

All applications/libraries must be able recognize the following name values:

library - This specifies the path to the pkcs #11 library.
name - This specifies the name of the pkcs #11 library.
parameter - This specifies a pkcs #11 library parameter with the application must pass to the pkcs #11 library at C_Initialize() time (see below).

In additions applications/libraries should be able to ignore additional name value pairs which are used to specify configuration for other applications. Of course these application/libraries should be able to parse their own name/value pairs.

Each of these name/value pairs are optional.

If the library is not specified, the line represents some application specific meta configuration data. Other applications and libraries can safely ignore this line.

If the name is not specified, the application can use the library path to describe the PKCS #11 library in any UI it may have.

If the parameter is not specified, no parameters are passed to the PKCS #11 module.

If the application/library does not find its application/library specific data, it should use it's defaults for this pkcs #11 library.

Parameter Passing:

If the parameter is specified, the application/library will strip the value out, processing any outter quotes and escapes appropriately, and pass the parameter to the pkcs #11 library when it calls C_Initialize().

A new CK_C_INITIALIZE_ARGS structure is defined as

typedef struct CK_C_INITIALIZE_ARGS {
  CK_CREATEMUTEX CreateMutex;
  CK_DESTROYMUTEX DestroyMutex;
  CK_LOCKMUTEX LockMutex;
  CK_UNLOCKMUTEX UnlockMutex;
  CK_FLAGS flags;
  CK_VOID_PTR LibraryParameters;
  CK_VOID_PTR pReserved;
} CK_C_INITIALIZE_ARGS;

Applications/libraries must set LibraryParameters to NULL if no parameter value is specified. PKCS #11 libraries which accept parameters must check if the 'new' pReserved field is NULL if and only if LibraryParameters field is not NULL.

NSS Specific Parameters in Module Specs

Here are the NSS Application specific parameters in use. This data is currently store in secmod.db. This isn't part of the generic spec (that is other applications need not parse it, nor pkcs #11 modules need supply them.

NSS="nss_params"
nss_params are themselves name/value pairs, parsed with the same rules described above. Valid names inside nss_params are:
flags - comma separated list of flag values, parsed case-insensitive. 
Valid flag values are:
   internal - this library is actually the Netscape internal library
   fips - this library is the Netscape internal fips library.
   critical - if this library cannot be loaded, completely fail initialization
   moduleDB - this library includes NSS specific functions to supply additional module specs for loading.
   moduleDBOnly - this library has no PKCS #11 functions and is only used for loading additional modules.
trustOrder - integer value specifying the order in which the trust information for certificates specified by tokens on this pkcs #11 library should be rolled up. '0' means that tokens on this library should not supply trust information (default). The relative order of two pkcs#11 libraries which have the same trustOrder value is undefined.
cipherOrder - integer value specifiying the order in which tokens are searched when looking for a token to do a generic operation (DES/Hashing, etc).
ciphers - comma separated list of ciphers this token will enable that isn't already enabled by the library (currently only FORTEZZA is defined) (case-insensitive)..
slotParams - space separated list of name/value pairs where the name is a slotID and the value is a space sparated list of parameters related to that slotID.
Valid slotParams values are:
   slotFlags - comma separated list of cipher groups which this slot is expected to be the default implementation for (case-insensitive).
    Valid flags are:
        RSA - This token should be used for all RSA operations (other than Private key operations where the key lives in another token).
        DSA - This token should be used for all DSA operations (other than Private key operations where the key lives in another token).
        RC4 - This token  should be used for all RC4 operations which are not constrained by an existing key in another token.
        RC2 - This token  should be used for all RC2 operations which are not constrained by an existing key in another token.
        DES - This token  should be used for all DES, DES2, and DES3 operations which are not constrained by an existing key in another token.
        DH - This token should be used for all DH operations (other than Private key operations where the key lives in another token).
        FORTEZZA- This token should be used for all KEA operations (other than Private key operations where the key lives in another token), as well as SKIPJACK operations which are not constrained by an existing key in another token.
        RC5 - This token  should be used for all RC5 operations which are not constrained by an existing key in another token.
        SHA1 - - This token should be used for all basic SHA1 hashing.
        MD5 - This token should be used for all basic MD5 hashing.
        MD2 - This token should be used for all basic MD2 hashing.
        SSL - This token should be used for SSL key derivation which are not constrained by an existing key in another token.
        TLS - This token should be used for TLS key derivation which are not constrained by an existing key in another token.
        AES - This token  should be used for all AES operations which are not constrained by an existing key in another token.
        RANDOM - This token should be used to generate random numbers when the application call 'PK11_GenerateRandom'.
        PublicCerts - The certificates on this token can be read without authenticating to this token, and any user certs on this token have a patching public key which is also readable without authenticating.
     
   rootFlags - comma separated of flags describing any root certs that may be stored (case-insensitive).
    Valid flags are:
       hasRootCerts
       hasRootTrust
   timeout  - time in minutes before the current authentication should be rechecked.
   askpwd   - case-insensitive flag describing how password prompts should be manages:
        every
    r

Sample file:

library= name="Netscape Internal Crypto Module"   parameters="configdir=/u/relyea/.netscape certprefix= secmod=secmod.db" NSS="Flags=internal,pkcs11module TrustOrder=1 CipherOrder=-1 ciphers= slotParams={0x1=[slotFlags='RSA,DSA,DH,RC4,RC2,DES,MD2,MD5,SHA1,SSL,TLS,PublicCerts,Random'] 0x2=[slotFlags='RSA' timeout=50 askpw=only]}"
library=dkck32.dll name="DataKey SignaSURE 3600" NSS="TrustOrder=50 ciphers= " 
library=swft32.dll name="Netscape Software Fortezza" parameters="keyfile=/u/relyea/keyfile" NSS="TrustOrder=50 ciphers=FORTEZZA slotParams=0x1=[slotFlags='FORTEZZA']"
library=core32.dll name="Litronic Netsign"

---

Some rationale, questions, issues, and ways I would like to use this:

Rationale:

First, I like the idea of easily turning a spec into a single NULL terminated string. This allows me to provide interfaces in my library so applications can load a single PKCS #11 library by simply specifying the same string one would find in the 'database' file.

This is the primary reason for going to a single line of name value pairs rather than a stanza file format. Making the names case insensitive aids in hand editting the file format. Ideally it should be realitively easy to hand edit the file, so the parser should be realtively liberal in what it accepts.

Using multiple quote characters is more of a nesting issue. It allows one to use the same parser to handle application specific parameters without using a lot of escapes.

Issues:

Win32 file specs: should they have \'s in them or should the be specified as forward slashes '/' using \ as the escape character causes some problems with simple win32 filenames (which would have to take on the form c:\\winnt\\system32\\mydll.dll for instance).

Do we need any token specific flags that are generic (like those I specified for the NSS specific data)? If so is object ID the right way to specify the specific token?

Should we specify application/library specific names to have some heirarchy form (mozilla.NSS or aol.NSS)? or is a single level all that is needed?

Do we want to specify a global libraryID that we can use to refer to a specific PKCS #11 library across system boots?

My Usage:

One of the things I would like to be able to do is 'nest' configuration files. I'd like to have a specific application instance which may point to a machine-wide instance. The application would bootstrap with maybe something like:

"pkcs11libaryList=file parameter='/space/myapp/config/pkcs11list'"

which in turn has pkcs #11 modules to load and then a line like:

pkcs11libraryList=file parameter='/etc/pkcs11list'

which loads the machine wide pkcs #11 modules. If this is of generic interest we can specify a pkcs11LibraryList like this, otherwise I would just hide it in the NSS specific parameters.