Re: Progress on GNOME Certificate Store / gnome-keyring PKCS#11

[Simon Josefsson <simon josefsson org>]

Nate Nielsen <nielsen-list memberwebs com> writes:

> As I noted in another thread I'm working on an X.509 certificate and key
> store for GNOME. This will be based on PKCS#11 (ie: Cryptoki).
>
> Those interested can follow the progress here:
>
> http://live.gnome.org/GnomeKeyring/Cryptoki
>
> Any advice from interested or concerned folks is more than welcome.

Cool!  Do I understand correctly that you will serialize the PKCS#11
requests through a unix socket?  I think using unix sockets is a good
idea, the experience with gpg-agent, scdaemon etc indicate this
provides good isolation of programs and permit easy auditing.
However, I don't follow how the PKCS#11 requests are transmitted over
a unix socket -- AFAIK there is no serialized protocol of PKCS#11.
I'm probably grossly misunderstanding your architecture, but having
more information would be useful.

I will work on GnuTLS to make it aware of and support this.
Supporting Seahorse as the X.509 CA/key/certificate store would be
really good.  Whether it is through native PKCS#11 support, or some
simpler protocol to a unix-socket connected process that in turn may
talk PKCS#11 to other applications will is an open question.

As a first step of something simple that I can implement in GnuTLS,
how would I retrieve all CA certificates from seahorse using your new
interface?  Adding an API to make GnuTLS talk to seahorse and get the
CAs seems like a useful first contribution.

Btw, I'm still interested in working on integrating Kerberos-support
in Seahorse.  You suggested gnome-keyring instead earlier.  Since the
encryption keys will likely not be stored in gnome-keyring but rather
remain in /tmp/krb5cc_UID (because that is where MIT/Heimdal will look
for them), I think seahorse may conceptually be a better fit.  What do
you think?  I'm not sure.  I don't think I understand the conceptual
differences between seahorse, gnome-keyring and gnome-keyring-manager
fully.

Thanks,
Simon