User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 In order to use the certificates on an eToken you have to manually load the eToken module first. It would be very helpful if Mozilla would detect and load the module automatically. On Windows the necessary .dll is installed with eTokens RTE at windows\system32\eTpkcs11.dll. Reproducible: Always Steps to Reproduce: 1. 2. 3.

There isn't any standard means of discovery of installed PKCS11 modules. We surely don't want to hard-code path names of third party PKCS11 module shared libraries into any part of mozilla. We have, in the past (and maybe present) provided a way to automate the registering of PKCS11 modules with the browser via a signed jar file (or XPI file?) install script. So, maybe the answer is for the token vendors to register their modules with mozilla, just as plugins do.

On Windows the RTE is still needed for installation of hardware drivers so a XPI or similar way of installation is only half the solution. What will the vendors need in order to register the PKCS11 module in Mozilla, Firefox and Thunderbird during the installation of the RTE? If the solution is evangelism who will contact the vendors?

> If the solution is evangelism who will contact the vendors? I would say "their customers". Customers have pull with vendors. Other vendors do not.

OK. Is there any documentation on how to add module to Mozilla during installation of the RTE I can point the vendor to?

http://developer.netscape.com/docs/manuals/security/jmpkcs/jimpkcs.htm This documents how to do it for Netscape Communicator 4.x. Mozilla 1.x and Netscape 7.x should be compatible with this, but I do not know for certain if they are.

I have contacted the vendor and pointed them to this bug.

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

This is a general problem about loading PKCS #11 modules system wide, as opposed to in a particular application. this bug should stay open until this is resolved. Resolution of this bug depends on a definition from the PKCS #11 working group.

What's the status of this bug? I'm currently maintaining a Debian package for a security module that allows one to authenticate to websites using an electronic ID card. Conditionally enabling that system-wide would be a nice feature, but it currently isn't possible because of this bug; creating a security module database using 'modutil' and enabling the module in that one doesn't work, since firefox seems to ignore that file. It'd be nice if it didn't.

I think there could be something workable at the PSM level. PSM could scan a system directory for PKCS#11 modules and load them automatically.

In the light of changes that occurred in NSS 3.12.5 (related to https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX ), there might be something feasible. The main question I have is how PSM can get both worlds, i.e. initialize the secmod list from /etc/pki/nssdb *and* use its own configuration from the application user profile.

Wouter: This will fix that problem. Part of the goal here is to allow configuration of system wide preferences. Mike: There are 2 kinds of configuration in NSS. The configuration of the users certs/keys/hardware tokens, and the configuration of the security attributes. The former is handled through the databases. As of Fedora 12, opening /etc/pki/nssdb will now cause NSS to open both the system DB and a common user specific db shared by all the applications (so now certs and keys are shared between Firefox and Thunderbird, for instance). NSS provides a method (https://wiki.mozilla.org/) to update the common database with the current configuration from the database in the application user profile. The code actually merges the data into that common database because now that common database may have data from another profile as well. There is currently no change to the latter configuration. I have some initial thoughts on this, but it will probably be of the form: allow administrator of a system to optionally change nss default behavior, and to lock down policies (similar to the way export/domestic policies were implemented) and allow the applications to continue to exercise fine-grain, programmatic control of the configuration within those policies. bob

(In reply to comment #12) > NSS provides a method > (https://wiki.mozilla.org/) to update the common database with the current > configuration from the database in the application user profile. The code > actually merges the data into that common database because now that common > database may have data from another profile as well. Is that 2. under https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX ?

Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody. Search for kaie-20100607-unconfirmed-nobody

(In reply to Nelson Bolyard (seldom reads bugmail) from comment #1) > There isn't any standard means of discovery of installed PKCS11 modules. Eleven years later, this is no longer true (at least on Linux and other Unix-like systems). Those platforms use p11-kit and *do* have a system-wide configuration for which PKCS#11 modules to load. It even makes things really simple with p11-kit-proxy.so, which inspects the system configuration and then proxies all the appropriate providers as slots of itself. So you don't even *need* to link against libp11-kit and integrate with p11-kit directly (although there are advantages to doing so). I've filed bug 1161219 for this issue already, before finding this bug. Should I mark that one as a duplicate of this?