|
|
| Line 880: |
Line 880: |
| database and legacy databases have the same objects. In the case of certs and keys, | | database and legacy databases have the same objects. In the case of certs and keys, |
| the merge is a simple matter of identifying duplicates and not updating them. | | the merge is a simple matter of identifying duplicates and not updating them. |
| In the case of trust attributes, however, there are a number of choices:
| |
| # don't update duplicate trust (shared database copy wins).
| |
| # overwrite trust from the legacy database (legacy database copy wins).
| |
| # calculate the intersection of trust between them (take the least trusted values). (turning off trust wins).
| |
| # calculate the union of trust between the two (turning on trust wins).
| |
|
| |
|
| From the user perspective, each of these choices means that after the update:
| | Trust records are made up of several entries, such as one for SSL Server Auth, SSL Client Auth, S/MIME, etc. Each entry could have several values, including CKT_NSS_MUST_VERIFY, CKT_NSS_TRUSTED_DELEGATOR, CKT_NSS_TRUSTED, CKT_NSS_VALID, etc). |
|
| |
|
| # the application that just updated may then trust certs that it had previously marked untrusted, and may no longer trust certs that it had previously marked trusted.
| | Merge updates the trust records by the entries in that trust record separately: |
| # other applications that share the database may then trust certs they had previously marked untrusted, and may no longer trust certs that they had previously marked trusted. | | # if the trust record entries are identical, no update is done. |
| # all apps may find that they no longer trust certs that had previously been marked trusted. | | # if either trust record entry has an explicit unknown (CKT_NSS_TRUST_UNKNOWN) or invalid trust record entry (entry does not exist), then the one that is valid and known is used. |
| # all apps may find that they trust certs that had previously been marked untrusted. | | # if one of the trust record entries has hard trust attributes (Trust flags with NSS_TRUSTED or NSS_UNTRUSTED in the name) and the other has soft attributes (NSS_VALID or NSS_MUST_VERIFY) the entry with hard attributes is used. Hard trust attributes are attributes that will terminate a certificate validation. |
| | | # if non of these cases apply, then the value in the target database is preserved. |
| Option 3 is the most secure, Option 4 will break have less breakage. Trust
| |
| merge conflicts that are real conflicts (application 'A' turned off trust and
| |
| application 'B' turned on trust) are expected to be rare. The common case would
| |
| be application 'A' turned on SSL trust and application 'B' turned on email
| |
| trust. In this case Option 4 is clearly the correct choice.
| |
| | |
| From a programming point of view, NSS should pick a default and implement it.
| |
| Ideally no user interaction will occur.
| |
| | |
| Finally password entries are merge issues. If the two databases have different
| |
| passwords, the merged database will have to have a
| |
|
| |
|
| ===== Mozilla Applications ===== | | ===== Mozilla Applications ===== |