Confirmed users
308
edits
(→The NSS Certificate Nickname API: mention option of removing nickname APIs) |
(add FIPS section) |
||
| Line 26: | Line 26: | ||
==== PKCS#11 XPCOM APIs ==== | ==== PKCS#11 XPCOM APIs ==== | ||
Currently the platform exposes some PKCS#11 module APIs that include such functionality as getting a handle on the internal module, listing known modules, and searching for modules, tokens, and/or slots. Because the user's software token is now not the same as that returned by PK11_GetInternalKeySlot, these APIs must be special-cased to continue to behave as expected. For example, if the user searches for a module with a blank name, the internal module (as loaded by SECMOD_OpenUserDB) must be returned. | Currently the platform exposes some PKCS#11 module APIs that include such functionality as getting a handle on the internal module, listing known modules, and searching for modules, tokens, and/or slots. Because the user's software token is now not the same as that returned by PK11_GetInternalKeySlot, these APIs must be special-cased to continue to behave as expected. For example, if the user searches for a module with a blank name, the internal module (as loaded by SECMOD_OpenUserDB) must be returned. | ||
==== 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. | |||