Hi all,

...the story continues...

As a part of our project, we need to support TPM hardware as certificate 
source for client-authentication against client-auth-enabled services. Within 
Kolab context, these are mainly IMAPS, SMTPS, LDAPS and HTTPS. The tpm-tools 
suite and openCryptoki will serve as software layer between the TPM hardware 
and the NSS lib, talking to each other via the PKCS#11 protocol.

We have validated already that the NSS lib can make use of certificates stored 
in the TPM via openCryptoki. In Evolution and E-D-S, I have seen references to 
PKCS#11 in S/Mime context only, so I assume there is no infrastructure for 
SSL/TLS client auth via NSS/PKCS#11 as yet. Is this correct?

As far as the Camel lib goes, we have the situation that we will need to 
handle at least two instances. One in Evolution (which is there anyway) and at 
least one in the backends (E-D-S). As far as the EDS part goes, we would be 
able to configure NSS to use the TPM stack from within our plugin code. But 
foe Evo, I doubt it will be possible to do the same configuration from within 
the EPlugin, right? This would mean we needed to touch Evo code itself. Has 
anyone had any thoughts about this already?

As for implementation, we thought it might be a good idea to implement the TPM 
stuff separately from the Kolab plugin. This would mean to leave Camel alone 
and to integrate TPM usage with the NSS lib directly. Do you think this would 
be an appropriate approach? Have there been any efforts before to do something 
like this?

Questions galore, any input welcome. :-)
Best regards,


kernel concepts GbR        Tel: +49-271-771091-14
Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
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