Zitat von Martijn Brinkers <[email protected]>:
[email protected] wrote: > because of code-signing we digg around in secure timestamps according > to RFC 3161. This is a extension which is used to solve the problem of > expired certificates and the need to know if the certificate was valid > at time of signing. > As far as i know this would also apply to S/MIME so signed messages > can be validated even if the certificate in question is expired. > Does anybody know if this would be useful or even supported by > mailclients. If yes it may be worth to be added to Djigzo in the > future? Djigzo already contains a signed timestamp. This however is different from RFC 3161 because with RFC 3161 the document is timestamped by a trusted third party (TTP). The timestamp which is already added to every signed email is signed by the signer of the message and not signed by another party. I'm however not aware of any email client that can actually validate such a signed timestamp.
This seem to be true unfortunately. Some sources on the net even say that timestamps are not (yet) supported in S/MIME but maybe it is more the lack of support from the mailclients because RFC 3161 define it as x509 extension so S/MIME should be no problem as far as i can see.
Implementation wise, the hardest problem to solve would be to handle the case when the gateway is unable to connect to the TTP signing authority (for example the TTP is down). Signing by the TTP can take some time so all email has to be queued until the TTP handles the email. Another option would be to use a tamper proof timestamp device (like Christine mentioned). I know nCipher (now is now owned by Thales) has such a device but that's a pretty expensive device.
Like the case with the external directory this may be useable if there is a fallback like "don't timestamp if server is unavailable" but if there is no mailclient support it is for sure too much effort.
So in sum, it's a good idea but to make it scalable I think you'll need an expensive trusted and tamper proof device.
How is the problem with expired signatures supposed to be solved otherwise? If i change the system date all the formelry valid signatures in the inbox are treated as invalid signed and a warning is displayed. Not how it is supposed to work i think...
Any other methods available to get around the problem of "ageing" client signatures??
Regards Andreas
smime.p7s
Description: S/MIME Signatur
_______________________________________________ Users mailing list [email protected] http://lists.djigzo.com/lists/listinfo/users
