Hi Milan, Am Dienstag 13 September 2011, um 07:33:31 schrieb Milan Crha: > On Mon, 2011-09-12 at 13:16 +0200, Christian Hilberg wrote: > > We succeeded doing so for the following protocols: HTTPS, IMAPS, SMTPS. > > > > These are protocols handled by Camel and the underlying NSS library. In > > order to access the crypto token, we needed to supply a token PIN, which > > we were not able to pass from Evo to E-D-S in version 2.30 as "live" > > data (pass-and- forget). So we had to use a fake implementation: we > > store the user PIN along the rest of the account data and reading it in > > the backend via ESource. Clearly, this violates security (and we are > > saying to in our user manual), but it demonstrates that in principle, > > things are working. To get this thing right, we would need a means to > > ask for a security pin from within the backend, presenting a dialog to > > the user > > Hi, > with the current eds (upcoming 3.2.0) you can pass parameters via > ECredentials, same as you do with e_passwords_ask_password, thus yes, > this is doable from book/cal backends now too. Hum, is ECredentials something a backend can actively request? With NSS, we need to register an NSS callback function in our backend, which is called by NSS when NSS tries to open the token for the first time in the session. Since the token PIN should not be stored anywhere (and removed from memory once the token is opened), the callback function will be the one triggering a user dialog to be opened, the PIN entered, passed to the callback function and set in NSS. After that, the whole dialog stuff will be closed and gone. At least, that would be the right way of doing it. It's not a hard requirement for us now (politics have changed a little), but there may be similar requirements coming from other backends, so I thought of bringing this issue up. And if we get the functionality for little money, we can make use of it. > > However, there is one protocol, for which we failed to implement any > > demonstrator for client-certificate-based authentication using a hardware > > crypto device: LDAPS. The implementation in Evo uses the OpenLDAP lib as > > a protocol implementation, which in turn uses GnuTLS for security > > (version 2.1x < 2.12 at that time). > > The OpenLDAP 2.12 is kinda old. And if I recall correctly, they moved to > NSS as well, at least 2.4.23 seems to use NSS based on their changelog. > Thus, I would say, when you move to current eds, then you can be pretty > sure that the used OpenLDAP will be the one with NSS. Or you can add a > dependency to evolution-kolab on the OpenLDAP which fits you best. Oops, sorry -- I missed to clarify this better. The LDAP access (for addresses) I was talking about is the one implemented in Evo itself, not the backend variant. There, we hit the aforementioned problem. Maybe the new OpenLDAP with NSS support will enable us to do what we need, since Evo already provides infrastructure for requesting security PINs. Thanks for the hint! Kind regards, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.