On Tue, Oct 09, 2007 at 11:32:48PM +0300, Alon Bar-Lev wrote: > On 10/9/07, Kent Yoder <[EMAIL PROTECTED]> wrote: > > Having both pkcs11-helper and a pure pkcs11 interface is not > > competing with one another. Obviously there are use cases for > > both. > > Yes it is, it splits the efforts investing in focusing on improving > eCryptfs and after that, may be improving the PKCS#11 > implementation.
We will work on merging the key module that uses pkcs11-helper into the official ecryptfs-utils package. All key modules are going to continue be aliased according to their immediate API dependencies. libecryptfs_key_mod_openssl depends on the OpenSSL API (include/openssl/*.h calls), libecryptfs_key_mod_tspi depends on TSPI API (tspi_* calls), libecryptfs_key_mod_pkcs11-helper depends on pkcs11-helper API (pkcsh_* calls), etc. If there is ever an alternative library that provides similar functionality to pkcs11-helper, then we may wind up with a key module that is named after that alternative library (e.g., libecryptfs_key_mod_pkcs11-meta or libecryptfs_key_mod_pkcs11-manager). We are not going to exclude by default all potential future extensions on top of the PKCS#11 interface in our naming scheme by giving any one extension a generic alias. The only library that will ever be named libecryptfs_key_mod_pkcs11, if it ever winds up getting written, will be one that directly makes the API calls published in the RSA specification, with no intermediate data structures and logic in some other library: http://www.rsa.com/rsalabs/node.asp?id=2133 Such a key module will then be linked against anything that provides that API. Right now, openCryptoki is available in RHEL and SLES, and it fully implements the PKCS#11 spec, so that is likely to be the library that we would recommend as the implementation of the API calls if we decide to write a PKCS#11 key module in the near future. However, *any* correct and complete PKCS#11 implementation could be dropped in, and the key module will still function as expected. This libecryptfs_key_mod_pkcs11 does not exist, and it may never exist, so long as libecryptfs_key_mod_pkcs11-helper meets all of our requirements. We still need to spend some time evaluating it against requirements. With respect to implementing a "pkcs11" key module, pkcs11-helper already solves some very important problems for token management. I recognize that it makes these token management tasks more convenient. Hence, I am inclined to leverage this existing solution in a key module that eventually uses a PKCS#11 provider rather than re-implement a lot of its existing functionality in some generic PKCS#11 key module. You do not have to sell me on the code reuse angle; I wish that were the only factor we had to concern ourselves with, but the reality is, we also need to make sure that we are able to use the existing code in our specific solution stack of interest (RHEL and SLES). If that is not feasible for whatever reason, then we will have to look into other options. But we have to establish that pkcs11-helper is not the best way to meet our specific requirements before we run off and get started on some "competing" PKCS#11 key module that winds up re-implementing a bunch of code that has already been written in pkcs11-helper. So, given the existence of the pkcs11-helper key module, or some other key module that uses an API that provides similar functionality to pkcs11-helper, we may elect to never implement a "pkcs11" key module. It may be easier to just get pkcs11-helper integrated into the distributions so that PKCS#11 is fully available to our RHEL and SLES users. We cannot promise that this will happen, because it is not up to us; the vendors themselves have to make decisions about which packages they will or will not integrate and support. When it comes to the official eCryptfs package, we have to work with the vendors on this. Eventually, whatever the RHEL/SLES user winds up seeing will probably be identified as "PKCS#11 support" in the documentation, regardless of whether the key module is "pkcs11-helper" or "pkcs11" or "pkcs11-meta" or whatever. And in any event, regardless of what happens with a "pkcs11" key module in the future, the pkcs11-helper key module is there for non-RHEL/SLES users to benefit from. At the level of the filenames and the aliases, the key module will be named according to the immediate API that it uses. I think this is a perfectly reasonable way of identifying the key module. Thanks, Mike
pgpFLIzz6HELB.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ eCryptfs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
