106
edits
NSS Shared DB: Difference between revisions
Jump to navigation
Jump to search
m
spelling fixes and other minor changes
m (spelling fixes and other minor changes) |
|||
| Line 33: | Line 33: | ||
Optionally the databases could be combined into a single database, cert9.db, where private and public objects are stored in separate tables. | Optionally the databases could be combined into a single database, cert9.db, where private and public objects are stored in separate tables. | ||
<font color=red>Review input required: is there a preference between a single DB file or separate key and cert DB files | <font color=red>Review input required: is there a preference between a single DB file or separate key and cert DB files?</font> | ||
===== schema ===== | ===== schema ===== | ||
| Line 46: | Line 46: | ||
**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 can be handled in the following ways: | **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 can be handled in the following ways: | ||
**# add a 'record' value around each attribute, where meta-data can be stored in the record. one of the meta-data values is that the record is empty. | **# add a 'record' value around each attribute, where meta-data can be stored in the record. one of the meta-data values is that the record is empty. | ||
**# don't try to distinguish between a NULL attribute and a non- | **# don't try to distinguish between a NULL attribute and a non-existent one. | ||
**# store a special value which means 'NULL' when writing a NULL record. (This is the current proposal). | **# store a special value which means 'NULL' when writing a NULL record. (This is the current proposal). | ||
Out of band data necessary for the proper operation of softoken, but not reflected back to | Out of band data necessary for the proper operation of softoken, but not reflected back to NSS in general (currently this only applies to password entries), will be stored in separate tables in the database with their own schema. | ||
Database extension is accomplished in 2 ways: | Database extension is accomplished in 2 ways: | ||
| Line 65: | Line 65: | ||
'''sql:'''''directory1''[''':'''''directory2''] opens a shared database, | '''sql:'''''directory1''[''':'''''directory2''] opens a shared database, | ||
cert9.db (& key4.db) in ''directory1'' if cert9.db does exist. If the database does not exist, then ''directory2'' is searched for a libdbm cert8.db and key3.db. If ''directory2'' is not supplied, ''directory1'' is searched. <br/> | cert9.db (& key4.db) in ''directory1'' if cert9.db does exist. If the database does not exist, then ''directory2'' is searched for a libdbm cert8.db and key3.db. If ''directory2'' is not supplied, ''directory1'' is searched. <br/> | ||
'''extern:'''''directory'' open a sql-like database by loading an external module, a. la. rdb and | '''extern:'''''directory'' open a sql-like database by loading an external module, a. la. rdb and ''multiaccess:''. This option would not be implemented in the initial release, but the ''extern:'' keyword would be reserved for future use. | ||
Plain directory spec. For binary compatibility, we can treat the plain directory spec as the same as '''dbm:'''''directory''. In this case applications will not need to change for this release of NSS. (particularly unfriendly applications that want to tweak with the actual database file). Alternatively, we could treat it as '''sql:'''''directory''. In this case existing applications will get the benefits of shared databases immediately, though we risk breaking those aforementioned applications. <font color=red>Reviewer input | Plain directory spec. For binary compatibility, we can treat the plain directory spec as the same as '''dbm:'''''directory''. In this case applications will not need to change for this release of NSS. (particularly unfriendly applications that want to tweak with the actual database file). Alternatively, we could treat it as '''sql:'''''directory''. In this case existing applications will get the benefits of shared databases immediately, though we risk breaking those aforementioned applications. | ||
<font color=red>Reviewer input required: which default would you prefer?</font> | |||
When accessing the '''dbm:''' and '''multiaccess:''' directories, external shared library will be loaded with knows how to handle these legacy databases. This allows us to move much of the current mapping code into this shared library. | When accessing the '''dbm:''' and '''multiaccess:''' directories, external shared library will be loaded with knows how to handle these legacy databases. This allows us to move much of the current mapping code into this shared library. | ||
| Line 85: | Line 87: | ||
==== Other issues ==== | ==== Other issues ==== | ||
<font color=red> Review Input Requested: Question, should we 'mark' old cert8/key3 databases as having been used to upgrade the shared database? </font> The issue here is applications that were once separated, but now combined. It would be nice if the keys and certs in each of these databases were properly merged into the overall shared database. | <font color=red> Review Input Requested: Question, should we 'mark' old cert8/key3 databases as having been used to upgrade the shared database? </font> | ||
The issue here is applications that were once separated, but now combined. It would be nice if the keys and certs in each of these databases were properly merged into the overall shared database. | |||
Upgrade itself is an issue. Do we want to support automatic upgrade (as we do today for older cert db types), or do we want to supply the application with an upgrade tool. The complication comes when we need to upgrade multiple old databases into a new one. | Upgrade itself is an issue. Do we want to support automatic upgrade (as we do today for older cert db types), or do we want to supply the application with an upgrade tool. The complication comes when we need to upgrade multiple old databases into a new one. | ||
| Line 105: | Line 109: | ||
===== s_open ===== | ===== s_open ===== | ||
The database API consists of an | The database API consists of an initialization call, which returns an SDB data structure (defined below). | ||
CK_RV | CK_RV | ||
| Line 123: | Line 127: | ||
* keydb is the returned key SDB structure | * keydb is the returned key SDB structure | ||
(NOTE: the signature of this | (NOTE: the signature of this function is likely to change. <font color=red>Comments on how to change it would be appreciated.</font> | ||
Issues include:<br> | |||
1. Should cert and key versions be part of the API, or should they be part of the underlying database? | |||
2. The cert and key prefix values are missing and should be added. | |||
3. Do we need separate create flag or is the combined READ/WRITE/CREATE sufficient? | |||
4. need a way to supply the list of know attributes so old DB's can be updated and initialized properly? | |||
The returned SDB structure has the following format: | The returned SDB structure has the following format: | ||
| Line 159: | Line 169: | ||
* sdb_type is the type of database (key [aka private] or cert [aka public]). | * sdb_type is the type of database (key [aka private] or cert [aka public]). | ||
* sdb_flags specifies how the database was opened (ReadOnly, Create, etc). | * sdb_flags specifies how the database was opened (ReadOnly, Create, etc). | ||
* sdb_version specifies the version of the underlying sdb structure. This allows | * sdb_version specifies the version of the underlying sdb structure. This allows us to handle future expansion of the sdb data structure safely. | ||
us to handle future expansion of the sdb data structure safely. | |||
* The rest are function pointers to database primitives described next. | * The rest are function pointers to database primitives described next. | ||
| Line 168: | Line 177: | ||
int count, SDBFind **find); | int count, SDBFind **find); | ||
This function is the equivalent of PKCS #11 C_FindObjectsInit(). It returns a SDBFind | This function is the equivalent of PKCS #11 C_FindObjectsInit(). It returns a SDBFind context with is opaque to the caller. The caller must call sdb_FindObjectsFinal with this context if sdb_FindobjectsInit succeeds. | ||
context with is opaque to the caller. The caller must call sdb_FindObjectsFinal | |||
with this context if sdb_FindobjectsInit succeeds. | |||
===== sdb_FindObjects ===== | ===== sdb_FindObjects ===== | ||
| Line 216: | Line 223: | ||
const CK_ATTRIBUTE *template, int count); | const CK_ATTRIBUTE *template, int count); | ||
This function is the equivalent of PKCS #11 C_CreateObject(). The value of 'object' is chosen by the | This function is the equivalent of PKCS #11 C_CreateObject(). The value of 'object' is chosen by the implementer of sdb_CreateObject. This value must be unique for this sdb instance. It should be no more than 30 bits long. | ||
===== sdb_DestroyObject ===== | ===== sdb_DestroyObject ===== | ||
| Line 230: | Line 237: | ||
Get the password entry. This only applies to the private database. | Get the password entry. This only applies to the private database. | ||
<font color=red>Review input needed: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 | <font color=red>Review input needed: 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?</font> | ||
===== sdb_PutPWEntry ===== | ===== sdb_PutPWEntry ===== | ||
| Line 239: | Line 246: | ||
Writing a password entry will overwrite the old entry. | Writing a password entry will overwrite the old entry. | ||
<font color=red> Would it be better to define a 'metadata' operation where we call the database to put data that is not reflected through the PKCS #11 interface | <font color=red> Would it be better to define a 'metadata' operation where we call the database to put data that is not reflected through the PKCS #11 interface?</font> | ||
===== sdb_Begin ===== | ===== sdb_Begin ===== | ||