Changes

NSS uses delegates the responsibility for managing the list of PKCS#11 modules in the running process to a shared library, sometimes called the "Module DB library". This shared library has a file small API (NOT the PKCS#11 API) with functions to decide what output a list of PKCS #11 modules, including softokenadd a new PKCS#11 module to the list, and delete a PKCS#11 module from the list. The details of how the Module DB library stores its information about the PKCS#11 modules is entirely up to loadthe Module DB library.  In NSS 3.11 and before this file was secmodearlier releases, and in NSS 3.db and was 12 (when in dbm compatibility mode), NSS's Module DB library uses a Berkeley database file(commonly named secmod. db) to keep the information about the configured PKCS#11 modules.  In NSS 3.12 the file is (when in sql mode), NSS Module DB library uses a flat plain text file called named pkcs11.txtto store the information about configured PKCS#11 modules.All the information in that file is stored as a plain text string.  In both NSS 3.11 and NSS 3.12x releases to date, it the shared library for the Module DB library is possible to tell NSS to load a also the shared library which provides for NSS's softoken PKCS #11 modules to loadmodule, called but that is merely a ModuleDBconvention, and is not architecturally required. This module DB implements (RIGHT, BOB?) During NSS initialization, NSS passes a couple string of APIs which returns a application configuration information to the Module DB library, indicating whether the list of modulesis to be managed read-only or read-write, Adds a new moduleand certain other application preferences, and Deletes an old modulesuch as whether the PKCS#11 modules should optimize their behavior for maximum speed or minimum memory footprint. With one small mod  This document proposes to modify the pk11wrap code which controls this loading, loads and invokes the Module DB library. The proposed modification will make it will be possible for NSS to use a system to interpose it's own moduleDBsubstitute module DB library, different than the one NSS normally uses in the softoken shared library. This Such a substitute module DB library will receive the same string that the module DB library in softoken receives , the string which contains the application's NSS preferences (readonly database, optimization options, etc), and . The substitute library can act on this string.  In the simplest case, this module a Module DB library simply opens the user database, user retrieves and outputs a list of PKCS #11 modules, system database, and system PKCS #11 modulesinformation about them. In the future, this module a substitute library could tie back to utilize some sort of managed database and open things , select PKCS#11 modules according to the appropriate policy, and make system wide decisions on what database softoken databases to load . Such decisions could be based on the application's request, the application itself, and the system administrator's policy. Note: I gather that Bob is about to propose a new substitute Module DB library implementation that will cause softoken to be initialized with multiple slots, one containing the user's own cert and key DBs (e.g. ~/.pki/nssdb) and one containing some "system" DBs, likely containing trusted root CAs (e.g. /etc/pki/nssdb).