Changes

Jump to: navigation, search

NSS Shared DB

476 bytes added, 02:01, 26 January 2008
Shared Database Proposal
This will not be necessary if the merge operation has already completed,
or if the source DB had no password. To determine this, the application
calls a function to ask if the token in the DB slot is removable. '''FIX ME'' The
function to be called for that purpose has not yet been made public, so
those details are TBD. That needs to be corrected.
a) (optional) Call PK11_GetTokenName to get the name of the token. With
that name, you can be sure that you are authenticating to the source token. Skipping this step is not harmful, it is only necessary if the application absolutely needs to know which token the following PK11_Authenticate() will be called on. For most NSS applications the underlying password prompt system will properly disambiguate the appropriate password to the user.
b) Call PK11_Authenticate() to authenticate to the source token. This
function to retrieve the password.
If this step fails: stop. A Failure at this point is described in thewiki document below as "Exception A".
Otherwise, continue with step 4.
If this fails, stop.
If this call indicates that the token is NOT present, then something isfundamentally wrong in the NSS softoken engine. Applications should treat this the same asamiss. (More details needed here)an NSS initialization failure.
If this call indicates that the token name in the DB slot is now the
target token name, continue to step 6.
step will be to authenticate to the target DB token. This call allows
the caller to ensure that he is about the authenticate to the target
token, and to get the target token name string for prompts. NOTE: Again, this check is only necessary form applications which need to know exactly which password PK11_Authenticate() is prompting for. For most well written NSS applications this step is not needed.
Step 7: Call PK11_Authenticate to authenticate to the target token.
callback function to retrieve the password.
If this step fails: stop. A Failure at this point is described in thewiki document below as "Exception B".
Otherwise, continue with step 8.
The Source DB Unique identifier string will have been written into the
target DB, so that future attempts to merge the same DB will be detected
and avoided. Your application can continue forward using NSS. NSS will use the merged shared database for all it's database operations from this point forward.
Exeptions: exception A tool wishing . Application needs to decide what happens if the legacy passwordis not supplied. Application can choose to: # continue to perform only use the merge may stop herelegacy DB and try to update later. A product thatwishes # force NSS to mark legacy DB to be updated without actually updating the legacy DB (throwing away everything in the legacy DB).# force NSS to update those objects it can from the legacy DB, throwingaway private keys and saved passwords. exception B. Applications needs to decide what happens if the new shared DBpassword is not supplied. Application can choose to :# continue on to perform its normal function may do souse the legacy DB and try to update later.# force NSS to mark legacy DB to be updated without actually updating the legacy DB (throwing away everything in the legacy DB).Be sure # force NSS to do a clean shutdown before exitingupdate those objects it can from the legacy DB,throwing away private keys and saved passwords, and trust information from the legacy DB.# force NSS to reset the shared database password, throwing away private keys and saved passwords, and trust information rom the shared DB.
Notes:
Note 1: The actual merger may take place during step 1, or step 3b, or
step 7; that is, during the call to NSS_InitWithMerge or during either
string in the target DB and act as if the merger is complete. This is similiar to what happens in all previous versions of NSS during database update. See "Database Merge" below for how to recover from this.
====== Database Upgrade Underlying Implementation =========Upgrade complications=====
Upgrade complications only affect Type A applications. In order to merge a
done
 
 
 
exception A. Application needs to decide what happens if the legacy password
is not supplied. Application can choose to:
# continue to use the legacy DB and try to update later.
# force NSS to mark legacy DB to be updated without actually updating the legacy DB (throwing away everything in the legacy DB).
# force NSS to update those objects it can from the legacy DB, throwing
away private keys and saved passwords.
 
exception B. Applications needs to decide what happens if the new shared DB
password is not supplied. Application can choose to:
# continue to use the legacy DB and try to update later.
# force NSS to mark legacy DB to be updated without actually updating the legacy DB (throwing away everything in the legacy DB).
# force NSS to update those objects it can from the legacy DB,throwing away private keys and saved passwords, and trust information from the legacy DB.
# force NSS to reset the shared database password, throwing away private keys and saved passwords, and trust information rom the shared DB.
 
NOTE: Since we are potentially dealing with 2 different passwords, The
application needs to be clear to the user which password it needs.
===== Merge Conflicts (Mode 3A only) =====
===== Database Merge =====
 
While not necessarily a feature of shared database, it is an important tool for successful shared database deployments.
==== Layering ====
439
edits

Navigation menu