Load a PKCS#11 module for NSS to use

[Stef Walter]

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:
>>> Hi,
>>>
>>> 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
>> loading.
> 
> 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
   distro level.

 * ... 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
iteration.

Stef