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, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.