Re: gnome-keyring PKCS#11 config file /etc/xdg/pkcs11.conf[.defaults]

[Stef Walter <stefw collabora co uk>]

On 2010-12-22 12:03, Nikos Mavrogiannopoulos wrote:
> What is the format and contents of those files? If they are intended to be
> broadly used, I think the format should be kept as simple. If you have
> any suggestion on that, let me know to include it in the fosdem talk
> as a discussion point.

The format is in the "Desktop Entry Specification" [1] in the section
"Basic format of the file". It's a format that is widely used on the
linux desktop. I feel it's a great candidate for this purpose, and
allows things like loading multiple files and having sections from later
files override others.

In the /etc/xdg/pkcs11.conf.default and /etc/xdg/pkcs11.conf files we
use this feature.

The location of /etc/xdg comes from the "XDG Base Directory
Specification" [2] although I have not followed that specification to
locate the config files for security reasons. If this is to become a
standard, it stands to reason we may choose another location besides
/etc/xdg.

Other considerations if we were to formalize this config spec:

 * Do we want some config file in the user's home directory that is
   used in conjunction with the system configs?

 * The same consideration for the PKCS#11 Registry Directory [3].
   Currently there is no way for the user to install modules (only
   root). I personally see this as a non-issue (software is generally
   installed by root). But some other projects have user loadable
   pkcs11 modules (Mozilla NSS).

 * We need to make sure that when implementing anything to do with the
   user loadable stuff, that there is a clear way for an admin or distro
   to prevent the user config files from being used.

   For example one way to do this is have the system config refer or
   link to the location of the user config (via symlink or explicitly).
   This link can then be removed when the spec is used in a context
   where user loadable modules or user configuration is undesirable.

In any case, I've largely ignored the above issues when designing this
preliminary system.

>> In the files we use PKCS#11 URIs to identify which slots to use for
>> what. One problem is that there is no way to specify the module file
>> name in a PKCS#11 URI. This prevents us from an airtight identification
>> of the relevant PKCS#11 slot. I'll bring this up to the PKCS#11 URI authors.
> 
> Actually the -03 version of pkcs11url can specify the module. We use it already
> in gnutls to specify precisely an object. The options referring to library are:
> library-manufacturer, library-description and even library-version...
> Unless I didn't get what is meant by library.

Interesting.

Well I was referring to use of the actual module path in the URI. This
would provide an airtight link between the URI and the module that we
actually want to use for the trust assertions.

Do the library-manufacturer, library-description and library-version URI
arguments provide the same hard to spoof connection between the URI and
the module?

Cheers,

Stef

[1]
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html


[2] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

[3] http://wiki.cacert.org/Pkcs11TaskForce