On 10/9/07, Kent Yoder <[EMAIL PROTECTED]> wrote: > Hi Alon, > > > > Pulling keys out of a PKCS11 store and encrypting using openssl is > > > not talking pure pkcs11. So we'll name the provider pkcs11-helper. > > > Is that ok? > > > > Which keys? The public keys? I really don't understand what wrong with it. > > Yes, the public keys. Some libraries keep the public key in a > partially encrypted blob that is sent to the hardware to do the > crypto. (Yes, the public key crypto). Of course you can pull that > pubkey out and pass it around, but this isn't always the use case.
It always the case. As many providers don't even store the public key on token, I require user to install an X.509 certificate on token. The X.509 certificate may be self signed, but it needs to be exists so the public key may be fetched from the token, and the public key information may be extracted from standard X.509 structure and not PKCS#11 metadata. This solves 100% of PKCS#11 implementations. > > But these providers are out there, there is no point in supporting > > none existence perfect provider... Your application just won't work. > > 1. Yes, of course those providers are out there, that's why we're > accepting your code > 2. The provider does exist. Its called openCryptoki. So you wish to implement a different key module only for openCryptoki? Strange... Maybe you call this openCryptoki key module? :) As mine will work with all (almost). > 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. Best Regards, Alon Bar-Lev. ------------------------------------------------------------------------- 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
