106
edits
Changes
partial editorial pass - some wordsmithing - more to be done
== Shared Database Proposal ==
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.
=== Where we are today ===
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.
* secmod.db - stores the PKCS #11 module configuration.
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:
'''multiaccess:'''''appName''[''':'''''directory'']
Where:<br/>
''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.
==== schema ====
*The Attribute values will be stored as binary blobs.
**Attributes that represent CK_ULONG values will be stored as 32-bit values in network byte order.
**All For all other objectsattributes, byte order is already specified by PKCS #11.
**Private attributes will be encrypted with a PKCS #5 PBE in the same way the pkcs8 private and secret key data is encrypted today.
**Softoken will only set those attributes appropriate for the given object. If The attribute is not appropriate it will be left blank. (Note that sqlite does not distinguish between a NULL attribute and an empty one. This will be handled by storing a special value which means 'NULL' when writing a NULL record.
** integrity will be maintained by a PBE based MAC on critical attributes.
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.
===== Legal Attributes and objects =====
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.
*Stored in the key database:
===== Special coding for encrypted entries =====
Encrypted entries are stored in the database as pkcs5 PKCS5 encoded blobs.
SEQUENCE {
AlgorithmID algorithm,
==== User App Initialization and System App Initialization ====
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.
This design assumes that new NSS init functions will be defined for applications wanting to do 'standard user initialization', rather than building special knowledge into softoken or the database model. Note: This is different from the 2001 design, or and earlier prototype shared database, where the database code knew the location of the shared database.
==== Database Upgrade ====
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.
These applications will continue to use the legacy database support and the
old database format. The applications cannot take advantage of new features
in the shared database. In this Mode, the nssdbm3 shared library must be
present. No update from legacy DBM to sharable is needed in this casemode.
Summary:
Application Changes: none.
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.
Summary:
trust.
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.)
Summary:
Changes to aid in update
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=====
both databases.
In Mode 3, the new database may or may not be initialized. For the first mode 3
application, the new database will be uninitialized. NSS can procede proceed the with
the same procedure as Mode 2. When the second and subsequent applications
start, the new shared database will already be initialized with it's own