canmove, Confirmed users
937
edits
NSS Shared DB: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 10: | Line 10: | ||
* cert8.db - stores publicly accessible objects (certs, CRLs, S/MIME records). | * cert8.db - stores publicly accessible objects (certs, CRLs, S/MIME records). | ||
* key3.db - stores the private keys. | * key3.db - stores the private keys. | ||
* secmod.db - stores the | * secmod.db - stores the PKCS #11 module configuration. | ||
In addition:<br /> | In addition:<br /> | ||
| Line 27: | Line 27: | ||
''directory'' is an optional parameter pointing to an NSS non-shared database which NSS will use to update the shared database from on loading. | ''directory'' is an optional parameter pointing to an NSS non-shared database which NSS will use to update the shared database from on loading. | ||
NSS will find librdb.so (rdb.dll on | NSS will find librdb.so (rdb.dll on Windows) in its path and load it. This shared library is expected to implement a superset of the standard libdbm interface. The main entry point is rdbopen, which will pass the appName, database name, and open flags. The rdb shared library will pick a location or method to store the database (it may not necessarily be a file), then handle the raw db records from NSS. The library does not do any formatting of the data. | ||
=== What we want to do === | === What we want to do === | ||
We want to move key3 and cert8 into | We want to move key3 and cert8 into new SQL databases called key4.db and cert9.db. These databases will store the PKCS #11 objects currently stored or implied in cert8 and key3. | ||
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. | ||
| Line 37: | Line 37: | ||
<font color=red>Review input required: is there a preference between a single DB file or separate key and cert DB files?</font> | <font color=red>Review input required: is there a preference between a single DB file or separate key and cert DB files?</font> | ||
==== schema ==== | |||
The schema for the database will be simple. | The schema for the database will be simple. | ||
*Each row will represent an object. | *Each row will represent an object. | ||
| Line 45: | Line 45: | ||
**Attributes that represent CK_ULONG values will be stored as 32-bit values in network byte order. | **Attributes that represent CK_ULONG values will be stored as 32-bit values in network byte order. | ||
**All other objects, byte order is already specified by PKCS #11. | **All other objects, byte order is already specified by PKCS #11. | ||
**Private attributes will be encrypted with a | **Private attributes will be encrypted with a PKCS #5 PBE in the same way private and secret keys are 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 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. | ||
| Line 59: | Line 59: | ||
NOTE: * I'm not suggesting this be the design for handling the SSL mapping problem, only as an example for the kind of thing that can be added to the database even after this deployment. | NOTE: * I'm not suggesting this be the design for handling the SSL mapping problem, only as an example for the kind of thing that can be added to the database even after this deployment. | ||
==== Accessing the shared Database ==== | |||
In order to maintain binary compatibility, I propose extending the keyword usage in NSS as follows: | In order to maintain binary compatibility, I propose extending the keyword usage in NSS as follows: | ||
| Line 73: | Line 73: | ||
<font color=red>Reviewer input required: which default would you prefer?</font> | <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 | When accessing the '''dbm:''' and '''multiaccess:''' directories, external shared library will be loaded which knows how to handle these legacy databases. This allows us to move much of the current mapping code into this shared library. | ||
==== Secmod.db ==== | ==== Secmod.db ==== | ||
| Line 103: | Line 103: | ||
#The meaning of the stored data. | #The meaning of the stored data. | ||
Softoken (not the database) will manage | Softoken (not the database) will manage canonicalizing any CK_ULONGs, encrypting or decrypting private data blobs, and deciding what attributes an object should have and setting the appropriate defaults if necessary. | ||
Since softoken deals with PKCS #11 templates internally, its interface to the database will be in terms of those templates. | Since softoken deals with PKCS #11 templates internally, its interface to the database will be in terms of those templates. | ||
| Line 254: | Line 254: | ||
CK_RV (*sdb_Begin)(SDB *sdb); | CK_RV (*sdb_Begin)(SDB *sdb); | ||
Begin a transaction. Any write to the database (sdb_CreateObject, sdb_DestroyObject, sdb_SetAttributeValue) must be accomplished while holding | |||
a transaction. Transactions are completed by calling sdb_Commit to commit the change, | a transaction. Transactions are completed by calling sdb_Commit to commit the change, or sdb_Abort to discard the change. More than one write operation may be made while holding a transaction. Aborting the transaction will discard all writes made while in the transaction. | ||
===== sdb_Commit ===== | ===== sdb_Commit ===== | ||
| Line 262: | Line 262: | ||
Commit a transaction. Any write to the database (sdb_CreateObject, sdb_DestroyObject, sdb_SetAttributeValue) must be accomplished while holding | Commit a transaction. Any write to the database (sdb_CreateObject, sdb_DestroyObject, sdb_SetAttributeValue) must be accomplished while holding | ||
a transaction. Transactions are completed by calling sdb_Commit to commit the change, | a transaction. Transactions are completed by calling sdb_Commit to commit the change, or sdb_Abort to discard the change. More than one write operation may be made while holding a transaction. | ||
===== sdb_Abort ===== | ===== sdb_Abort ===== | ||
| Line 269: | Line 269: | ||
Abort a transaction. Any write to the database (sdb_CreateObject, sdb_DestroyObject, sdb_SetAttributeValue) must be accomplished while holding | Abort a transaction. Any write to the database (sdb_CreateObject, sdb_DestroyObject, sdb_SetAttributeValue) must be accomplished while holding | ||
a transaction. Transactions are completed by calling sdb_Commit to commit the change, | a transaction. Transactions are completed by calling sdb_Commit to commit the change, or sdb_Abort to discard the change. More than one write operation may be made while holding a transaction. Aborting the transaction will discard all writes made while in the transaction. | ||
===== sdb_Close ===== | ===== sdb_Close ===== | ||
| Line 284: | Line 284: | ||
# A private interface may be needed to unwrap the private keys, or provide a handle to the password so the keys can be presented in the attribute format. | # A private interface may be needed to unwrap the private keys, or provide a handle to the password so the keys can be presented in the attribute format. | ||
This code would live in its own shared library. Most of the low level cert, | This code would live in its own shared library. Most of the low level cert, CRL, key handling, and translation to PKCS #11 objects and attributes that was part of softoken will moved to this legacy shared library. It will be loaded whenever access to old databases is required. | ||
[[Category:NSS]] | [[Category:NSS]] | ||