> > 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.
I really hope you misunderstood what I meant here. I meant that it isn't always the case that you'll want to use openssl to do the public key operations. > 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 Another reason why pkcs11-helper can't be used everywhere... > 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. Except for the ones where no cert exists, right? > > 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. I disagree. I see use cases for both. By including both, we'd get support for tokens that that don't implement C_Encrypt and for fully featured pkcs#11 implementations. We'll let Mike make this decision. Kent -- Kent Yoder IBM LTC Security Dev. ------------------------------------------------------------------------- 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
