Re: gnome-keyring gck-rpc

[Stef Walter <stef-list memberwebs com>]

Tim Hudson wrote:
>> 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.
> It can be generically remoted for special values of 'generic' - where
> conversion routines are provided for each of the mechanism specific data
> structures and knowledge of the size of underlying vendor attribute
> extensions in order to determine if they are meant to be CK_ULONG size
> or some other size. There is unfortunately not a defined way of
> communicating this information to an application - it just has to be
> encoded.

Yeah, I agree with you, it's all possible. I mean gnome-keyring remotes
PKCS#11. But the metadata to make this work really well is missing.

>> However large swaths of PKCS#11 either cannot be remoted easily, or do
> not make sense to remote.
> I'm simply going to have to agree to disagree on this one - they can all
> be remoted - and they all make sense to remote. The remoting is not as
> trivial as it could be if PKCS#11 had taken a different path for
> specification of mechanism specific parameters or provided some method
> of communicating meta-data to the application.

No disagreement here. I just said that it wasn't easy to remote PKCS#11.

>> ... PKCS#11 does not have the concept of multiple applications using a
> PKCS#11 in a shared memory space.
> You'll have to expand on the issue you are talking about here - as
> PKCS#11 does indeed have the concept of applications and sessions and
> goes to some length to explain mappings etc - although that part of the
> specification is not what I'd call the easiest section to read through.

One example is that the login state is not per session, but per
slot/application. So if multiple 'applications' are using pkcs11 in a
single memory space then all get logged in at the same time.

Another example is that session objects are not visible per session, but
per slot/application. So again if multiple 'applications' are using a
pkcs11 module in a single memory space, then they all see the session
objects.

gnome-keyring ran into this limitation, but other projects and uses may
not. gnome-keyring extends PKCS#11 so that a variety of applications can
all have independent sessions in the gnome-keyring-daemon process.


Anyway, I guess the point I'm making in all of this is not that it's
impossible to do. Obviously it's all possible. I mean gnome-keyring
itself does a much of what we're discussing... We have all sorts of
work-arounds and bits of arcane code here and there to work around
deficiencies in PKCS#11. However it certainly does work, and it's pretty
stable and maintainable.

When I started working with PKCS#11 I imagined this nice world of
exciting pluggable PKCS#11 components, that could be configured in all
these different ways. I was designing parts of gnome-keyring to be like
that. However I think that the reality seems to be closer to: No user
serviceable parts inside.

I don't mind helping other PKCS#11 developers use things like gck-rpc in
their applications, as long as they're willing to get their hands dirty
when things break. I don't feel like I want to get into support this
sort of thing for *users* to configure stuff together on their own
generically.

Please understand I'm not dissing PKCS#11, but I think I've just become
a lot less starry eyed about it :)

Cheers,

Stef