[kmf-discuss] design review request for KMF pluggability enhancements

[Huie-Ying Lee]

Currently, all three plugins in KMF (key management framework) are hard-coded
in libkmf and KMF is unable to accomodate additional plugins automatically.
This enhancement will provide capabilities for users to add/remove additional
plugins dynamically.

My preliminary proposal has been reviewed by the KMF core team.  Below is
the updated design, and I would appreciate any comments by Oct/12/2007.

Thanks,
Huie-Ying


=======================================================
A New Private configuration file: /etc/crypto/kmf.conf
=======================================================
The KMF configuration file is "/etc/crypto/kmf.conf" with permission
"644".   This file specifies only non-default keystore plugins with the
following format:

   keystore_name:module_path=xxx[;option=option_str]

       The "keystore_name" field specifies the keystore name.

       The "module_path" field specifies the pathname to a KMF plugin shared
       library object.   If the pathname is not absolute, shared library
       objects are assumed to be relative to /usr/lib/security/$ISA/.
       The ISA token is replaced by an implementation  defined directory name
       which defines the path relative to the calling program's instruction
       set architecture.

       The option field specifies an option string which would only
       be processed by the plugin.

==================================================
Changes to the kmfcfg command
==================================================
1) A new "install" subcommand will be added to the kmfcfg command.

    $kmfcfg install keystore=keystore_name modulepath=path [option=option_str]

    This command installs a new plugin into the Key Management framework.
    Internally, a new entry for this plugin will be added into the
    /etc/crypto/kmf.conf file.


2)  A new "uninstall" subcommand will be added to the kmfcfg command.

    $kmfcfg uninstall keystore=keystore_name

    This command will uninstall the plugin with the kstype name.
    Intenally, the entry with the keystore name will be removed from
    /etc/crypto/kmf.conf file.

3) A new "plugin" parameter will be added to the list subcommand.

    $kmfcfg list plugin

    - This command displays all the plugins in the system, including 3 default
      plugins.  For example, if there is an additional plugin in the system,
      the output will look like

    $kmfcfg list plugin
    pkcs11:kmf_pkcs11.so.1 (built-in)
    file:kmf_openssl.so.1 (built-in)
    nss:kmf_nss.so.1 (built-in)
    new_plugin:/opt/lib/new_plugin.so.1;option=debug

    Note that without the "plugin" keyword, "kmfcfg list" will show the policy
    stuff as before.

4) A new "modify plugin" subcommand will be added to the modify subcommand.

    $kmfcfg modify plugin keystore=keystore_name option=option_str

    This subcommand allows an admininstrator to modify the plugin option.
    The plugin option is defined by the plugin and will be interpreted by the
    plugin specifically, therefore this command will accept any option string.

==================================================
Changes to libkmf
==================================================
1) Changes to kmf_initialize()

    In kmf_initialize(), the 3 default plugins will be loaded first.

    If there is any new plugin in the /etc/crypto/kmf.conf file, the new
    plugins will be loaded sequentially and a new keystore type (a number
    actually, starting from 4) will be assigned to each new plugin.

    Internally, a global extra_plugin_list for all the additional plugins will
    be created after the first kmf_initialize() is called.  Once it is set,
    this global extra_plugin_list will not be changed through out the
    lifetime of the process.


2) A new get_plugin_info() API will be added.

KMF_RETURN
kmf_get_plugin_info(KMF_HANDLE_T handle, char *keystore_name,
     KMF_KEYSTORE_TYPE *kstype, char **option)

     kstype_name - input
     kstype      - output
     option      - output

This function takes a keystore name as input and returns a new
KMF_KEYSTORE_TYPE value.   If the option argument is not NULL, then
this function will return the plugin option if this is a plugin option.

Note that the returned "kstype" value should be used to access the new
plugin's SPI.


=========================================================
New plugin package requirement and class action scripts
======================================================
For a new plugin library, we would like it to be installed into the Key
Management Framework during the pkgadd time and uninstalled during the pkgrm
time automatically.  To achieve this, two class action scripts will be added
in the /usr/sadm/install/scripts directory.

    i.kmfconf -> the installation class action script
    r.kmfconf -> the removal class action script

Accordingly, the new plugin package should do the following:

    1. Add the "kmfconf" class into the CLASSES string of the pkginfo.tmpl
       file.

    2. Create an input file "kmf.conf" in the "etc/crypto" directory and
       The syntax of the input file is same as the kmf.conf file

       keystore_name:module_path=xxx[;option=xxx]

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kmfcfg.1.new
Url: http://mail.opensolaris.org/pipermail/kmf-discuss/attachments/20071004/61b80854/attachment.ksh 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kmfcfg.1.diff
Type: text/x-patch
Size: 1557 bytes
Desc: not available
Url : http://mail.opensolaris.org/pipermail/kmf-discuss/attachments/20071004/61b80854/attachment.bin