81358 - The internal pkcs11 module should be a loadable module.

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P2)

Description

[zhoubin]

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.

Comment 1

[Wan-Teh Chang]

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?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 3

[Robert Relyea]

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

Comment 4

[Robert Relyea]

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.