Re: gnome-keyring gck-rpc

[Stef Walter <stef-list memberwebs com>]

I hope it's okay that I've CC'd your email to gnome-keyring-list.

Tim Hudson wrote:
> I've been looking at your PKCS#11 RPC interface (having written a few
> before in previous roles and now needing one I went looking for an open
> source solution).
> Thanks for making that code available. I've got a usage perhaps outside
> of the context you intended (or perhaps not).
> 
> I've taken the code and basically fixed up a few bugs and made it
> buildable outside of GnomeKeyring (and without glib) which was pretty
> straight forward given the clean code and then I've added support for
> using 'ssh' to form a secure connection to a remote server (pretty much
> the way cvs, svn, and git treat the transport interface as an external
> replaceable construct).

Interesting. I'm a intrigued/concerned about using such high level
constructs for the transport mechanism, when PKCS#11 can be and is used
to implement things like SSH agents and stuff.

> Is this something you'd be interested in getting a patch to add into the
> base distribution or is it something you'd prefer to see maintained
> outside of the GnomeKeyring tree?

But the main problem I've run into, is the assumption that PKCS#11 can
be generically remoted. I started with this assumption, but I was proven
completely wrong.

There is a subset of PKCS#11 which gck-rpc is able to remote. Thankfully
that includes things like RSA key and Certificate usage. However large
swaths of PKCS#11 either cannot be remoted easily, or do not make sense
to remote.

First of all, PKCS#11 definitely assumes that the application and module
share memory space. For example, take a look at many of the CK_MECHANISM
pParamater contents for various mechanisms. They often contain pointers
to random bits of memory, which would be a complete hack per mechanism
to implement.

Check out gck_rpc_mechanism_has_sane_parameters() and
gck_rpc_mechanism_has_no_parameters() in gck-rpc-util.c

Attributes with CKF_ARRAY_ATTRIBUTE like CK_WRAP_TEMPLATE and
CK_UNWRAP_TEMPLATE are a real pain to implement, although gnome-keyring
will probably need them at some point, and it isn't going to look
pretty. Again they assume shared memory space.

But the problems get worse ... A massive show stopper is the combination
of multiple applications accessing a module living in the same memory
area. A single instance of a PKCS#11

But the problems get worse, on the server side. When you have a server
(like gnome-keyring-daemon) handling requests from multiple applications
in a shared memory space you run into the fact that PKCS#11 does not
have the concept of multiple applications using a PKCS#11 in a shared
memory space. gnome-keyring implements somewhat hacky extensions to make
this work.

In the future it's very likely that gnome-keyring's PKCS#11
implementation will try to take these realities further into account,
rather than try to waltz around them with hacks...

One final thing, is that applications dealing with PKCS#11, by and
large, assume they're dealing with an module nearby. For example if you
using gnome-keyring's --with-root-certs, and then use your SSH protocol
for remoting, and then hook that up to firefox, you'll find that opening
up the CA certificate list, is unbearably slow.

PKCS#11 isn't really designed to be used like this. It's an ok API for
applications to keys, but really not much more. If I had more than one
lifetime, I probably would have chosen CDSA for use in gnome-keyring.

> The changes at the moment are pretty straight forward and clean - but
> I'm looking at making a pile more changes to support calling
> cross-platform (different endian handling and different CK_ULONG size
> handling) which will tend to impact more of the code.
> 
> Or alternatively would you like to see separate bug fixes entirely
> independent of the 'features' I'm adding?

Yes, the first thing I'd love to check out is the bug fixes. That'd be
super appreciated. We could include them for version 2.30.

Cheers,

Stef