Hi Alon, > > > > > Here you are wrong. > > > pkcs11-helper provide the ability to access the PKCS#11 industry standard. > > > Please try the patchset and see for yourself that the solution allows > > > eCryptfs to access any PKCS#11 provider. > > > > I understand, I'm just pointing out that its non-standard ways of > > doing things will not be acceptable for some, so we should name it > > something unique. > > Why none standard way?
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? > pkcs11-helper uses standard PKCS#11 calls to a standard PKCS#11 provider. > Application that uses pkcs11-helper use standard PKCS#11 providers. > Since PKCS#11 standard is not closed standard in term what needed to > be supported, how and when, using PKCS#11 is very complex task. > Implementing the same complex task in many applications time after > time is not wise, this why software engineers came up with this great > idea of code reuse, shared library or dll. I see the problem here -- PKCS#11 providers suck. :-) You have no control over what they implement and since none of them have implemented any software slots in their providers, you're forced to use a workaround (pkcs11-helper). That's too bad, but it doesn't change the fact that some providers don't suck, and code will use one provider at a time and only interface to that provider (no external openssl interface). Therefore, we must have a pure pkcs11 interface in ecryptfs, therefore, your helper must have a different name. That is seriously what this issue boils down to for me. > You implement a complex task one time and allow many applications to > use it. Fixing/improving the library affect the whole chain, so > everyone happy. > > But I am sure you know all the above... But for some strange reason > you think PKCS#11 is an exception... I cannot figure it out. No, its not an exception at all. Some time in the future, there will exist a token where we will want to call C_Encrypt and C_Decrypt using the PKCS#11 key handle, straight from the ecryptfs PKI API. That's the use case that keeps us from calling your token interface "pkcs11" instead of "pkcs11-helper". > > > Why? It takes about 2 seconds to do this using most smartcard > > > hardware... And less than 0.1 second to do this on main CPU... > > > > Why should it? PKCS#11 was designed in such a was that what > > pkcs11-helper is doing shouldn't even need to happen. Under the > > covers of your smart-card token you should implement the RSA > > mechanisms with an openssl interface. All operations then just flow > > through PKCS#11 in the same slot and token with no need for a new > > interface. Worst case you could use a separate software only slot and > > *still* not need multiple PKCS#11 providers. > > You are wrong. > PKCS#11 was designed to allow flexible implementation, so flexible > that you don't have to implement almost anything. This just goes back to my previous point, you have no control over what's going into these providers, and so they lack s/w fallback. Those using a provider that does provide s/w fallback shouldn't have to go through your extra layer. > From my experience, and please let's assume you accept that I have > some experience in this field, most providers implement the minimum > required functionality. Apparently so... please see my previous comments. > Another wrong statement you have written is "... that what > pkcs11-helper is doing shouldn't even need to happen" pkcs11-helper > does not do anything! I have OpenSSL interface to ease integration No comment. :-) > But anyway this discussion is irrelevant, as I am offering you to have > PKCS#11 feature *NOW*, if you wish to implement a different > implementation, you can, nothing should be changed in any of the > interfaces, you wish to drop OpenSSL usage, pkcs11-helper usage etc... > Just do it in the future, why holding feature from users? In the mean > time we improve eCryptfs implementation so it will enable support of > dynamic hardware configuration. I haven't read all of this thread, but I haven't heard anyone say your feature won't be accepted. 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 eCryptfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-devel
