439
edits
Changes
→How NSS decides what to load
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. [Bob in general this is correct. Module DB's are loaded through the same mechanism as PKCS #11 modules. There are flags to say if a module is a Module DB, PKCS #11 module or both. Softoken is, in fact, loaded as both a Module DB and a PKCS #11 module (RIGHT, BOB?rather than a single module that can do both)]
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.
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). [long answer from bob: Indirectly. NSS will still use the softoken's ModuleDB to bootstrap. The proposal is that applications will open the system db '/etc/pki/nssdb', which will trigger the normal loading of softoken as a moduleDB to load the pkcs11.txt file stored in /etc/pki/nssdb. Softoken, however, has code which treats the internal module differently. It does 3 things with the internal module: 1) it modifies the parameter string to match the parameters passed in to NSS init, and 2) it arranges for the internal module to be loaded first (This makes sure the internal module is available for any services needed when loading other modules, like cipher checks or RNG entropy mixing*, and puts softoken on the bottom of the 'preferred modules for various operations'. That way softoken can always be overridden).3) there must be an internal module. If none are specified, the softoken module DB creates a default one and automatically adds it to the existing pkcs11.txt (if it's writable). The new PKCS #11 module allows users to hand edit pkcs11.txt and put the parameters in quotes (""). This allows users to override application parameter settings, so #1 can be overcome. To overcome 2 and 3, this document is proposing that we allow non-NULL library= specifications for the 'internal' module. Currently the pk11wrap layer which interprets the module strings ignores the library= value if the type is 'internal'. The proposal is that we continue to accept NULL library= and type=internal to mean softoken, but if library= points to some other module, then we load that module as 'the internal module'. This means in practice we bootstrap with softoken, but the operating system could completely replace the use of softoken if it wants by hooking into pkcs11.txt. *NSS mixes Entropy from softoken into other PKCS #11 modules that support RNG and pulls entropy from those modules into softoken. This allows for hw seeding of the RNG simply by providing a PKCS #11 module which support rng. It also allows software PKCS #11 modules to take advantage of NSS's initial seeding for their key generation.]
= Certificate/Key Migration =
