NSS Shared DB And LINUX: Difference between revisions

NSS Shared DB And LINUX (view source)

Revision as of 08:57, 23 December 2008

1,553 bytes added , 23 December 2008

Attempt major clarification of "How NSS decides what to load"

Nelsonb

106

edits

@@ Line 68: / Line 68: @@
 = How NSS decides what to load =
-NSS uses a file to decide what PKCS #11 modules, including softoken, to load. In NSS 3.11 and before this file was secmod.db and was a Berkeley database file. In NSS 3.12 the file is a flat text file called pkcs11.txt. In both NSS 3.11 and NSS 3.12, it is possible to tell NSS to load a shared library which provides PKCS #11 modules to load, called a ModuleDB. This module DB implements a couple of APIs which returns a list of modules, Adds a new module, and Deletes an old module. With one small mod to the pk11wrap code which controls this loading, it will be possible for a system to interpose it's own moduleDB. This module will receive the same string that softoken receives which contains the application's NSS preferences (readonly database, optimization options, etc), and can act on this string. In the simplest case, this module simply opens the user database, user PKCS #11 modules, system database, and system PKCS #11 modules. In the future, this module could tie back to some sort of managed database and open things according to the appropriate policy, and make system wide decisions on what database to load based on the application's request, the application itself, and the system administrator's policy.
+NSS 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 small API (NOT the PKCS#11 API) with functions to output a list of PKCS#11 modules, add 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 the Module DB library.
+In NSS 3.11 and earlier releases, and in NSS 3.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 (when in sql mode), NSS Module DB library uses a plain text file
+named pkcs11.txt to store the information about configured PKCS#11 modules.
+All the information in that file is stored as a plain text string.
+In NSS 3.x releases to date, the shared library for the Module DB library is also the shared library for NSS's softoken PKCS#11 module, but that is
+merely a convention, and is not architecturally required.  (RIGHT, BOB?)
+During NSS initialization, NSS passes a string of application configuration information to the Module DB library, indicating whether the list is to be managed read-only or read-write, and certain other application preferences, such as whether the PKCS#11 modules should optimize their behavior for maximum speed or minimum memory footprint.
+This document proposes to modify the pk11wrap code which loads and invokes the Module DB library.  The proposed modification will make it possible for NSS to use a substitute module DB library, different than the one NSS normally uses in the softoken shared library.  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.  The substitute library can act on this string.
+In the simplest case, a Module DB library simply retrieves and outputs a list of PKCS #11 modules and information about them.  In the future, a substitute library could utilize some sort of managed database, select PKCS#11 modules according to the appropriate policy, and make system wide decisions on what 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).
 = Certificate/Key Migration =