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

[Stef Walter <stefw collabora co uk>]

On 01/19/2011 10:07 AM, Nikos Mavrogiannopoulos wrote:
> On 01/19/2011 04:20 PM, Stef Walter wrote:
> 
>> Good, makes sense. Although do we need that to be more fine grained 
>> saying which mechanisms are accelerated? FWIW, NSS has the concept of
>> a set of mechanisms for which a PKCS#11 module is the default
>> provider. You can see this in modutil. Does something like that make
>> sense for this configuration file.
> 
> Those are related. The latter option allows for more fine-tuning. Do you
> suggest something like:
> acceleration=PKCS11_METHOD?

Yes, a comma leparated list like that sounds good. I would suggest using
the mechanism constant without the 'CKM_' prefix:

CKM_RSA_PKCS -> 'RSA_PKCS'

> Something like that is an overkill in embedded systems, as it would
> require a special library to handle all this configuration. I think that
> a configuration like that should be simple.

Yes, but an embbeded system could easily just use one configuration file
even though multiple are supported.

As a developer of many PKCS#11 modules I have no idea how I would
package and install them without the support for either:

 a) Multiple configuration files in /etc/pkcs11 that are each
    considered.
 b) Putting the module in a special directory like /usr/lib/pkcs11

But perhaps I'm missing some part of the picture. Could you explain how
you would package or install a pkcs11 module without support for the
above? Obviously I'm not talking about manual user involvement in the
install like editing of files. I'm talking about either 'make install'
or a package RPM/DEB etc..

Standards like PAM started off with a single configuration file, and
then in later versions were forced to allow multiple configuration files
(used together) as a solution to the above install problem. PAM also has
many implementations.

Lastly, although having multiple configuration files is more complex
than having one, it is far simpler than other technologies which we are
reimplementing in multiple places: namely PKCS#11 URI support.

>> On the other hand, the simplicity of having a special directory
>> where you place (or link) modules that should be loaded is very
>> appealing.
> 
> There always be the problem of wanting to have a library conditionally
> (i.e. a debug library), and removing and copying is more work than
> changing a config file. And since a config file is available anyway
> (for other reasons)... then it's best to use it for that purpose as
> well.

As we see above (barring solutions I'm not seeing), in the absence of
having a special directory like this, we pretty much need multiple
configuration file support. If that's too complex, then I think that
having a special directory is the next best workable thing.

Cheers,

Stef