Talk:NSS Shared DB: Difference between revisions
(fix some headings) |
No edit summary |
||
| Line 3: | Line 3: | ||
1. I have heard good arguments both for and against combining the two DBs. | 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. | 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. | 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. (Your response could go here) | |||
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) | |||
== Review input required: Accessing the shared Database: which default would you prefer? == | == Review input required: Accessing the shared Database: which default would you prefer? == | ||
Revision as of 06:27, 2 March 2007
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)
- (Your response could go here)
- (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.
- (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?
- (Your response could go here)