On 10/10/07, Kent Yoder <[EMAIL PROTECTED]> wrote: > > 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...
Yes it can, there is no PKCS#11 provider I know (and I know many) that don't support adding X.509 certificate object. > > 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? Almost any configuration already has X.509 certificate, and if not, any provider allow adding self-signed certificate. From my experience users have no objection to do so, for example OpenSSH and GnuPG PKCS#11 support require that and user are happy to comply, even though X.509 is not used directly by application. > > > 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. I don't think you understand me correctly, the C_Encrypt may be added at later time, and adding it correctly, also suggest using a optionally *DIFFERENT* provider for public cryptography, this will achieve your goal more correctly. There is no "Fully featured PKCS#11 implementation", this term is not part of the PKCS#11 specification, there is no reason to invent terms locally for eCryptfs. Just in order to support [only] providers that support C_Encrypt you will implement and maintain another low level PKCS#11 implementation... This sounds very strange to me. Please notice that OpenSSL do support acceleration engines so that using correct configuration the RSA public key operation will be performed on external hardware, achieving your goal even better without modifying current code. 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
