Load a PKCS#11 module for NSS to use

[Watson Sato]

On Tue, Aug 12, 2014 at 5:32 AM, Stef Walter <stefw at redhat.com> wrote:

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

This kind of explains the crashes while trying to unload the module, even
when not using p11-kit.


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

Thanks for all the answers.
For now I'll try to do it without p11-kit, if needed it will be added later.

-- 
Watson Yuuma Sato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/p11-glue/attachments/20140812/4229b0cc/attachment-0001.html>