Confirmed users
299
edits
Security/CryptoEngineering/Platform Use of NSS: Difference between revisions
Jump to navigation
Jump to search
Security/CryptoEngineering/Platform Use of NSS (view source)
Revision as of 18:06, 2 December 2016
, 2 December 2016→Remaining Issues: add resolved issues section
(→The NSS Certificate Nickname API: update to note that this has been resolved) |
(→Remaining Issues: add resolved issues section) |
||
| Line 15: | Line 15: | ||
PK11SDR_Encrypt and PK11SDR_Decrypt have no equivalent functions that take a caller-provided slot. Either new functions will have to be added to NSS (e.g. as PK11SDR_EncryptOnSlot and PK11SDR_DecryptOnSlot) or they will have to be reimplemented in PSM. Luckily, these two functions do not call internal NSS APIs and can be easily duplicated in terms of functionality. Doing so might be desirable as it would enable a step towards towards using more modern cryptography to protect the information in the user's key database. | PK11SDR_Encrypt and PK11SDR_Decrypt have no equivalent functions that take a caller-provided slot. Either new functions will have to be added to NSS (e.g. as PK11SDR_EncryptOnSlot and PK11SDR_DecryptOnSlot) or they will have to be reimplemented in PSM. Luckily, these two functions do not call internal NSS APIs and can be easily duplicated in terms of functionality. Doing so might be desirable as it would enable a step towards towards using more modern cryptography to protect the information in the user's key database. | ||
==== Loading New PKCS#11 Modules ==== | ==== Loading New PKCS#11 Modules ==== | ||
| Line 31: | Line 24: | ||
==== FIPS ==== | ==== FIPS ==== | ||
Continuing to support FIPS with these changes appears to be problematic in two ways. First, since from NSS' perspective the "internal" database is loaded in memory-only mode, that the user put the database in FIPS mode isn't persisted across restarts. This can be addressed by a mechanism similar to or along side that which persists new PKCS#11 modules (see above). Second, turning on FIPS mode appears to unload the real persistent certificate and key database. It may be that this can simply be reloaded as part of the process of enabling FIPS. Further investigation in required here. | Continuing to support FIPS with these changes appears to be problematic in two ways. First, since from NSS' perspective the "internal" database is loaded in memory-only mode, that the user put the database in FIPS mode isn't persisted across restarts. This can be addressed by a mechanism similar to or along side that which persists new PKCS#11 modules (see above). Second, turning on FIPS mode appears to unload the real persistent certificate and key database. It may be that this can simply be reloaded as part of the process of enabling FIPS. Further investigation in required here. | ||
=== Resolved Issues === | |||
==== The NSS Certificate Nickname API ==== | |||
NSS exposes APIs whereby certificates can be referred to by nickname. Certificates on tokens other than that returned by PK11_GetInternalKeySlot prefix their nickname with the name of the token. Because platform code now must operate on a token that isn't the internal one, this behavior must be worked around by special-casing unprefixed nicknames when using these and related APIs. | |||
Alternatively, we could remove and/or rework XPCOM interfaces that expose the NSS nickname API and replace them with an equivalent mechanism that doesn't have this and other drawbacks (see the discussion in [https://bugzilla.mozilla.org/show_bug.cgi?id=857627 bug 857627]). | |||
Update: As of the landing of bug 857627, this shouldn't be an issue any longer. | |||