439
edits
Changes
long answer deleted
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 : 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 (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.
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 short answer from bobBob: 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) yes -- long answer deleted because 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 was 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 softokensequitor, but if library= points to some other module, then we load that module as 'the internal module'. This means look in practice we bootstrap with softoken, but the operating system could completely replace the use of softoken history 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 generationyou care about mechanics.]
= Certificate/Key Migration =
