Load a PKCS#11 module for NSS to use
stefw at redhat.com
Tue Aug 12 01:32:57 PDT 2014
On 12.08.2014 10:18, David Woodhouse wrote:
> On Tue, 2014-08-12 at 09:38 +0200, Stef Walter wrote:
>> On 12.08.2014 08:12, Watson Sato wrote:
>>> I'm a GSoC student and I'm developing a PKCS#11 module for Evolution.
>>> I'm about to integrate it into Evolution, and planning to load it by
>>> calling SECMOD_LoadUserModule().
>>> Some people recommended me to take a look on other approaches, like Gck
>>> and p11-kit.
>>> For what I have tried and tested, with both approaches I managed to load
>>> and initialize the modules. But the references to the modules remain in
>>> the application, and I need NSS to be able to use the module.
>>> Is there a way for an application to load a PKCS#11 module and make it
>>> available to NSS with p11-kit?
>> Well, sorta ... You can use the p11-kit-proxy.so module. By using that
>> all configured p11-kit modules become available to NSS.
>> But I think what you're trying to do SECMOD_LoadUserModule() is the
>> perfect function to use. As I understand it, you're not trying to build
>> a globally configured/installed module, but rather something specific to
>> the running Evolution process. There's no need to involve p11-kit in the
> Yes and no.
> In fact, this module is exposing X.509 certificates from Evolution
> addressbooks. Yes, the *primary* use case is for Evolution itself, so
> you can send S/MIME-encrypted mail to someone in your addressbook, and
> you don't throw your computer out the window in frustration when it says
> it has no certificate for them.... despite clearly showing the
> appropriate X-CERT-X509 field when you look at their addressbook entry.
This is indeed a very good thing to fix.
> But actually, there's no reason why the data in the same PKCS#11 module
> shouldn't be made available to other crypto users in the general case...
> which is where p11-kit comes in.
Perhaps, but you'll quickly get into the weeds here. It's all possible
... but it's not that pretty.
* You'll *definitely* want to use the 'isolate' functionality in
p11-kit 0.21.x, since GLib (and by extension Camel, and whatever) is
not unloadable and would crash when your PKCS#11 module is unloaded.
* Make sure to use a *enable-in* directive so random PKCS#11 aware
applications (as in stuff using gnutls) don't try to load EDS just
because they load your module. Whitelist the use of your module.
* In order to use NSS with p11-kit you currently have to use
p11-kit-proxy.so ... so loading your module is dependent on
p11-kit configuration. You have no explicit control here from within
evolution, although you can configure things appropriately at a
* ... and I'm sure there's several more issues that will eventually
make you cry. Solvable yes ... but painful.
I think you're overcomplicating the actual real world use case above by
dragging all this in. I would again suggest making it work with
Evolution first, and then worrying about everything else in a later
More information about the p11-glue