Hi all.

During the initial implementation of the evolution-kolab plugin, we were 
concerned with using hardware crypto devices (TPM, trusted platform module) as 
a means to store and retrieve client certificates for securing TLS connections 
to a Kolab server (by configuring the Kolab server to require certificates for 
client authentication).

  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 (not necessariy via Evo, maybe the 
new ESources and account management stuff Matt is working on could help with 
that). We've succeeded here _only_ since Camel uses the Mozilla NSS lib for 
securing connections.

  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 combination of OpenLDAP and GnuTLS did not allow us 
to get things flying regarding the use of hardware crypto devices via the PKCS 
#11 interface. Where NSS only needs a token PIN and figures out either 
automatically or via external configuration files which of the possibly 
multiple client certificates to use, GnuTLS needs an URI which fully 
determines exactly which location inside the token to read the client 
certificate from, no automatisms here. While this allows for the application 
to control which cert to use (and not relying on any automatism, which may or 
may not work as needed), it requires the application to do it. Now, if on top 
of GnuTLS sits some protocol library like OpenLDAP, which rightfully denies to 
be bothered with security details of the underlying transport lib, we've got a 
problem: we must break the strict top-down layer approach and configure GnuTLS 
first, then use the protocol lib like OpenLDAP. We would have needed to hack 
around this directly in Evo to solve this, which clearly was (and probably is) 
out-of-scope for the evolution-kolab project.

My question now is, how are the plans for Evo and E-D-S to handle these 
things, mid-term and long-term? Are there plans to favor any single one 
security lib, or will there be a multitude of different libs be used? GnuTLS 
is sort of home-made, while NSS is alien but works for the issue described 
above (which, admittedly, is a little esoteric, but *maybe* symptomatic?). In 
GnuTLS, I've seen much progress with PKCS #11 (like the integration of p11-
kit), but it requires more details to be handled by the application itself.

I'm looking forward to reading your input,
Kind regards,


kernel concepts GbR        Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen

Attachment: signature.asc
Description: This is a digitally signed message part.

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to