106
edits
Talk:NSS Shared DB: Difference between revisions
Update to first "for" argument
(Update to first "for" argument) |
|||
| (4 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
== 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? == | == 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. | 1. <Nelson> 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. | 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. | ||
(Update: Actually, the issue isn't secrecy of the cert DB contents, but rather integrity (authenticity). There are third party tools today that claim to be able to operate directly on NSS DBs. The worry is that someone might inject a new CA cert and mark it trusted, without the knowledge of the DB's rightful | |||
owner.) | |||
| Line 16: | Line 23: | ||
3. (Your response could go here) | 3. (Your response could go here) | ||
== Suggested changes for PKCS #5 PBE == | |||
1. Use a larger iteration count. It is [http://www.drh-consultancy.demon.co.uk/key3.html 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? == | == Review input required: Accessing the shared Database: which default would you prefer? == | ||
| Line 21: | Line 40: | ||
- (Your response could go here) | - (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? == | == Review Input Requested: Should we 'mark' old cert8/key3 databases as having been used to upgrade the shared database? == | ||
| Line 27: | Line 50: | ||
== s_open: the signature of this function is likely to change. Comments on how to change it would be appreciated. == | == 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) | - (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? == | == 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) | - (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? | |||