Changes

NSS has not updated it's been using an old version of the Berkeley DataBase as its database format engine since 199xNetscape Navigator 2. Over 0 in 1994. That version of the years the restrictions created by the current database engine is commonly described in NSS documents as "DBM". That engine has become more accutea number of limitations. Of these restrictions, One of the most severe limitations concerns the lack number of the ability processes that may share a database file. While any process has a DBM file open for applications to writing, NO other process may access it in any way. Multiple processes may share certificate and key a DBM database has been one of the more severeONLY if they ALL access it READ-ONLY. As more applications use NSS, the need for each one to manage Processes cannot share a DBM database separately becomes unnecessary overheadfile if ANY of them wantsto update it.

In 2001 we built some tools to work around those restrictions so certain This limitation has been cumbersome for applications could share the database if they supplied their own shared database implementation, and configured NSS that wish to use NSS. Applications that implementation. Today we want to share databases have a process level, ACID, open source, and widely available database called SQLite. In addition, there is a strong desire to make NSS the system security service for Linux. I am proposing how we could leverage this database resorted to give all of our applications Shared Database access.these strategies:

Besides *Synchronized updates, with application down time: The applications share the database read-only. If any update is desired, all the applications are shut down, and a database update program performs the update, then all the applications are restarted in read-only mode. Some server products, for example, have an administration program that stops the servers, updates the database that they share, and then restarts the servers. This results in undesirable downtime and desired database changes are delayed until the next interval in which such downtime is acceptable.*Multiple copies with duplicated updates. Each application keeps its own copy of its databases, and applications communicate their changes to each other, so that each application may apply received changes to its own DB. FireFox and Thunderbird are examples of this. When one of those applications gets a new certificate and private key, the user may "export" that pair to a PKCS#12 file, and then import that file into the other application. Most users never master these steps, and so have databases entirely out of sync. These workarounds for the DBM engine's limitations are sufficiently onerous that they prevent many applications from adopting NSS. The desire to makeNSS more ubiquitous now motivates the lack elimination of these limitations. There is a strong desire to make NSS be the native OS network security service for Linux. In 2001 NSS was modified to enable applications to supply their own database engines. Applications could share a common database if they supplied their own shared database implementation, and configured NSS to use it.  Today, there exists a process level, ACID, open source, and widely available database engine with which multiple processes may simultaneous have read and write access to a shared database. It is named SQLite. The NSS team proposes to leverage this database to give all NSS-based applications Shared Database access. Besides the inability to share databases, other issues with the current NSS DBM database scheme include:# The need for a A more flexible schema which can handle storing more store meta information about certificates and keys, particular such as finer grain grained information about the trust of a certificatefor certificates.# The need to match the underlying certificate and key storage with it's its reflection into NSS (that is , PKCS #11).# To satisfy the FIPS requires requirements for integrity checks on critical keys and trust objects. We need to , NSS must be able to store that integrity information in the databasedatabases.

At initialization time, NSS currently takes an argument which points to some directory the application gives NSS a string that it uses as the pathname of a directory to store its private NSS's security and configuration data. NSS uses typically stores 3 libdbm dbm files in that directory: * cert8.db - stores publicly accessible objects (certs, CRLs, S/MIME records).* key3.db - stores the private keys.

In additionAlso in that directory:<br />* NSS may also use a directory called cert8.dir to store If it has very large blobs security objects (typically such as large CRLs), NSS will store them in files in a subdirectory named cert8.dir.* If the cert8.db and/or key3.db files are missing, NSS may will read data from from previous certificate database older versions of those databases (e.g., cert7.db, cert5.db, etc.if they exist) and may build a new cert8.db if and/or key3.db files. These files are all accessed exclusively by the softoken shared library, making it doesn't existthe only NSS library that must be linked with libdbm.

If the directory argument passed initialization string given to NSS starts with the string 'multiaccess:', NSS does not use it as a directory pathpathname. Instead, NSS parses the string out as follows:

''multicaccessmultiaccess'' is a keyword.<br/>''appName'' is uniquely identifies a unique string for each group of applications which share the anapplication-supplied database, effectively a new databasename.<br />''directory'' is an optional parameter pointing the pathname for a directory containing NSS DBM databases whose contents will be used to an update the application-supplied database during NSS initialization. In the presence of a multiaccess initialization string, during initializationNSS non-will try to find a shared database named librdb.so (rdb.dll on Windows) in its path and load it. This shared library is expected to implement a superset of the old dbm interface. The main entry point is rdbopen, which NSS will use be passed the appName, database name, and open flags. The rdb shared library will pick a location or method to update store the shared database (it may not necessarily be a file), then handle the raw db records from on loadingNSS. The records passed to and from this library use exactly the same schema and record formats as the records in the DBM library.

NSS will find librdb.so (rdb.dll on Windows) in its path and load it. This shared library is expected to implement a superset of the standard libdbm interface. === The main entry point is rdbopen, which will pass the appName, database name, and open flags. The rdb shared library will pick a location or method to store the database (it may not necessarily be a file), then handle the raw db records from NSS. The library does not do any formatting of the data.proposal ===

=== What we want We propose to do ===replace key3.db and cert8.db with new SQL databases called key4.db and cert9.db. These new databases will store PKCS #11 token objects, the same types of objects whose contents are currently stored in cert8.db and key3.db

We want to move key3 and cert8 into Optionally the new SQL databases called could be combined into a single database, cert9.db, where private and public objects are stored in separate tables. Softoken would automatically identify any cert9.db that also has an embedded key store and open that key store up, instead of opening a separate key4.db and cert9.db. These databases However, in the first release, there will store the PKCS #11 objects currently stored or implied in cert8 be no way to create a cert9.db containing both cert and key3key tables.

Optionally the The new databases could will be combined into a single database, cert9called 'shareable' databases.db They may or may not be shared by multiple processes, where private and public objects but they are stored in separate tables. Softoken will automatically identify any cert9.db which has an imbedded key store and open that key store up. By default a separate key4.db and cert9.db will be opened. In the first release there will be no way to create a combined cert/keydball capable of being shared.

**All For all other objectsattributes, byte order is already specified by PKCS #11.

Out of band Other data that is necessary for the proper operation of softoken, but that is not reflected back to NSS in general defined as part of any PKCS#11 objects, (currently this only applies such as data used to password entriesverify token user passwords), will be stored in separate tables in the database with their own schemaschemas.

Database extension is will be accomplished in 2 ways:# New attributes are added to attribute types can augment the list known attributes and to already defined PKCS #11 -implemented attribute types for objectsalready implemented in softoken. Older Attributes of these new types can be added to older database objects can , which will be detected because they will have 'invalid' values for these attributes (. For example, we could add CKA_TRUST_EXTENSION_OVERRIDE a new attribute type to trust hold additional extensions for certificate objects to add or override existing certificate extensions).# Add Define new PKCS #11 objects to hold the data (object types. For example, we could add a new SSL_DATA record objects to store mappings to between various certificates to different pairs of cipher suites and host name*)names.

Softoken will be able to store the following objects and attributes. In the table below, attributes marked CK_ULONG will be written to the database as a 32-bit network byte order unsigned integer, attributes integers. Attributes marked 'encrypted' will be encrypted with the token's pbe key, and attributes marked 'MACed' will be MACed with the token's pbe PBE key.

While the key and certificate database format is extensible, the initial implementation has to understand a particular subset of attributes. The following list the attributes and of attribute types will be understood, and any special coding conditions for that given those attributetypes.

Encrypted entries are stored in the database as pkcs5 PKCS5 encoded blobs.

One of the goals of making a shared shareable database version of NSS is to create a 'system crypto library' in which applications will automatically share database and configuration settings. In order for this to work, applications need to be able to open NSS databases from standard locations.

Because there are some semantic differences between To understand the issues of migration to the Shared Shareable Database versionof NSS and from the traditional database(legacy) versions, We really have 3 we group applications that use the new version of NSS into three 'modes ' of operation for the NSS , and shared databasesinto two types, of which there are five valid combinations.

Mode 1: Legacy applications which formerly used DBM databases, that upgrade to the new version of NSS withoutmaking any changes to the application itselfapplications' code.

present. No update from legacy DBM to sharable is needed in this casemode.

Mode 2: Applications which maintain private that use the new shareable database engine, but choose not to share copies of their certs cert and key stores . They wish to keep separate copies of their databases. They may or may not have existing legacy DBM databases from older versions of those applications. (various Some servers, for instancemight be like this.).

These applications will use the shared new shareable databaseengine. The first time the new application version runs, when NSS first creates the shareable databases, NSS will automatically detect instances of legacy databases when first creating the shared database and will upgrade those legacy databases to the new shareable ones without user interaction.

Mode 3: Applications which that intend to share their keys and certs with other applications (the common case - browsers, mail clients, secure shells, vpns, etc.)

These To achieve that sharing, these applications will must share a single common database. In order for this to work,these applications must all open the same set of databases. Currently If older versions of theseapplications have their own independent copies of the created legacy DBM databases, those legacy databases. These independent copies must be merged. In order or NSS to complete this To perform such a merge, itNSS will need some extra support from the application itself, and possibly user intervention as well.

Type A: Type A applications are new versions of applications that existed before NSS supported sharable databases. They have existing legacy NSS databases. These The new versions of these applications have been upgraded to the new NSSthat supports shareable databases. If they intend to share the contents of those old databases, and they need to merge the old databasesdatabase contents into the new ones.  All Mode 1 applicationsare type Aand need nssdbm3 at all times. All Mode 2 and Mode 3 applications of Type A applications need nssdbm3 to either upgrade or runfrom the old legacy DBM databases to the new shareable databases. Mode 3 Type A applications need libnssdbm3 to merge data from legacy DBM databases into shareable ones. Mode 2 and Mode 3 type A applications do not need nssdbm3 except for upgrading and merging data from old legacy databases.

Type B: Type B applications are applications ported to that never used any old version of NSS after the new shareddatabase codethat supported only DBM databases. All NSS databases used by Type B applications are sharable databases. There are no legacy DBM databases for Type B applications. All Type B applications should be are either Mode 2 or Mode 3. Type B applications need do no update interactionsdatabase upgrades, nor and do the not need nssdbm3.

=====Update Upgrade complications=====

Updated Upgrade complications only affect Type A applications. In order to merge a legacy database into an existing shared shareable database, NSS needs the password for

application, the new database will be uninitialized. NSS can procede proceed the with