The internal pkcs11 module should be a loadable module(We do not load it),so we can only use the certifcates and cryptogram service in other device other than in internal pkcs1 moudle.
Assigned the bug to Bob. zhoubin: do you have a practical need to reduce the binary size, or is this for an architectural reason -- to make the internal pkcs11 module look and behave the same as any other pkcs11 module?
Assignee: wtc → relyea
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → 3.4
Version: unspecified → 3.2.1
Presently, NSS has dependencies on code in the internal module that is not accessed via the PKCS#11 API. There are several reasons for this, including (but not limited to) the following: 1. The PKCS#11 API does not provide all the necessary "mechanisms" to do SSLv2 and certain other things that NSS does. 2. The "temporary" cert DB is part of the software token, but it also used to keep track of certs across all tokens; that is, it is used inside the token and outside of it. Even if all actual crypto work is being done by another token, NSS needs the temp cert db code which is part of the software token. 3. The software token presently does not provide access to all its contents via the PKCS#11 API. So, the code that searches for certain types of certs uses a different API to search the soft token than to search the other tokens. (The original plan to convert the software crypto code into a software token was supposed to obviate multiple crypto service provider APIs, but apparently hasn't). So, a lot of work needs to be done to NSS and the software token before it will make any sense to separate the software token from the rest of the NSS3 DSO/DLL.
Leave this bug open as a future enhancement. Many of the changes Nelson meantioned I intend to make in the 3.3 time frame, but there is additional work to completely pull the internal module out as loadable. One note, the functionality the user is requesting is really independent of making the internal module loadable. You can already use certs and keys to a certain extent with loaded modules. The primary purpose of the 3.3 work in the certificate code is to make that 100 %. You can also force out the internal module for all of it's services today. The only reason to make it fully loadable is to verify that we really have completed all the work, and to allow for reduced footprint. bob
In NSS 3.4, the internal module is now 'loadable'. NSS still reverences it by symbols rather than looks it up and fetches the entry point, but it is a complete shared library with no exported symbols except the 3 entry points.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.