Talk:NSS Shared DB

Other issues with the current NSS database scheme

1. If the databases are corrupted, NSS malfunctions and our users don't know how to recover from bad database errors.

Review input required: is there a preference between a single DB file or separate key and cert DB files?

1. I have heard good arguments both for and against combining the two DBs.

For: The cert DB contains trust information and therefore is just as security sensitive to the user as the contents of the private keys. It should be password protected (encrypted) just as the key DB already is.

Against: Today, as a debugging aid, we occasionally ask users to send us copies of their cert DB. We remind them that their cert DB contains no private keys, and this usually satisfies them that they can send their cert DBs without worry of key compromise. We should retain that characteristic, that the DB (or set of DBs) has a separable part that can easily and safely be sent to others.

2. <from Bob> In the For response above, note that the encrypted requirement would change some of the design. It would make us unable to access certificates and trust without logging into the token (we wouldn't be able to verify a certificate change, for instance, without a password prompt). This is already true of FIPS mode, however.

Other For: Copying a single database is administratively easier than trying to keep 2 databases which are linked to each other together, and less error prone.

Other Against: While Trust may be security sensitive, it is also public information. One may want to add file system protections for the key db that is separate from the cert db.

3. (Your response could go here)

Suggested changes for PKCS #5 PBE

1. Use a larger iteration count. It is publicly known that we use a low iteration count now.

2. Use the standard PBKDF2 rather than our extension of PBKDF1 (PBKDF1Extended).

3. Remember to perform integrity check (MAC) on the private attributes.

Comments on the proposed keywords

I suggest using sqlite: instead of sql:.

Review input required: Accessing the shared Database: which default would you prefer?

[richm] I think for the initial release "dbm:" should be the default. For the next release, "sql:" should be the default and perhaps "dbm:" should be deprecated, assuming it is desirable to get rid of "dbm:" in the future. But this really depends on the upgrade/migration strategy. If my application will just automatically convert my existing cert8/key3 to the new format, then the default could be "sql:".

- (Your response could go here)

Comments on secmod.db

Steve Parkinson suggested that we replace secmod.db with a directory of text files, with one file for each PKCS #11 module. Then the records for different PKCS #11 modules can be easily added or modified independently.

Review Input Requested: Should we 'mark' old cert8/key3 databases as having been used to upgrade the shared database?

- (Your response could go here)

s_open: the signature of this function is likely to change. Comments on how to change it would be appreciated.

I added 'const' to the 'char *directory' parameter.

- (Your response could go here)

Review input needed: sdb_GetPWEntry and sdb_PutPWEntry: Would it be better to define a 'metadata' operation where we call the database to fetch data that is not reflected through the PKCS #11 interface?

Should we add 'const' to the 'SDBPasswordEntry *entry' parameter of the sdb_PutPWEntry function?

- (Your response could go here)

int vs. CK_ULONG

The 'count' and 'arraySize' parameters of several sdb_XXX functions are declared with the type 'int'. They should be an unsigned type. Since they are used with arrays of PKCS #11 types CK_ATTRIBUTE and CK_OBJECT_HANDLE, should we declare them with the PKCS #11 type CK_ULONG for consistency?