# Timestamp support for e-mail signing **URL:** \ **Category:** Gateway\ **Created:** [May 4, 2010, 8:37am UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115 "2010-05-04T08:37:35Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![lst\_hoe021](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lst\_hoe021](https://community.ciphermail.com/u/lst_hoe021)\ **Post date:** [May 4, 2010, 8:37am UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115/1 "2010-05-04T08:37:35Z")
Hello 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? Regards Andreas ---
**Author:** ![Christine](https://avatars.discourse-cdn.com/v4/letter/c/8491ac/32.png) [@Christine](https://community.ciphermail.com/u/Christine)\ **Post date:** [May 4, 2010, 10:23am UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115/2 "2010-05-04T10:23:09Z")
> Hello > > 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? I think that would be a useful feature. But in order to generate good timestamps, you need to have proper hardware to generate the timestamps, like the hardware that nCipher is selling. This would require an investment from the party hosting the timestamp server. Alternatively, Djigzo could provide the extension to generate the timestamp from a third party server. This would require availability of such a server during development. dagdag Christine > **···** > > On 05/04/2010 10:37 AM, lst\_hoe02(a)kwsoft.de wrote: > > > Regards > > > > Andreas > > -- > dagdag is just a two-character rotation of byebye. ---
**Author:** ![martijn](https://dub1.discourse-cdn.com/flex017/user_avatar/community.ciphermail.com/martijn/32/127_2.png) [@martijn](https://community.ciphermail.com/u/martijn)\ **Post date:** [May 4, 2010, 11:24am UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115/3 "2010-05-04T11:24:48Z")
lst\_hoe02(a)kwsoft.de 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. 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. 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. > **···** > > -- > Djigzo open source email encryption ---
**Author:** ![lst\_hoe021](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lst\_hoe021](https://community.ciphermail.com/u/lst_hoe021)\ **Post date:** [May 4, 2010, 11:35am UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115/4 "2010-05-04T11:35:57Z")
Zitat von Martijn Brinkers \: > lst\_hoe02(a)kwsoft.de 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 ---
**Author:** ![lst\_hoe021](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lst\_hoe021](https://community.ciphermail.com/u/lst_hoe021)\ **Post date:** [May 4, 2010, 11:39am UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115/5 "2010-05-04T11:39:09Z")
Zitat von Christine \: > > Hello > > > > 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? > > I think that would be a useful feature. But in order to generate good > timestamps, you need to have proper hardware to generate the timestamps, > like the hardware that nCipher is selling. This would require an > investment from the party hosting the timestamp server. > Alternatively, Djigzo could provide the extension to generate the > timestamp from a third party server. This would require availability of > such a server during development. > > dagdag > Christine The availability should not be a problem as for example [https://tiemstamp.geotrust.com/tsa](https://tiemstamp.geotrust.com/tsa) (Verisign) or [http://www.startssl.com/timestamp](http://www.startssl.com/timestamp) (StartSSL) could be used. The bigger problem would be scalability and the lack of support from mailclients i guess. Anyone aware of a mailclient capable of timestamp support?? Regards Andreas > **···** > > > On 05/04/2010 10:37 AM, lst\_hoe02(a)kwsoft.de wrote: ---
**Author:** ![martijn](https://dub1.discourse-cdn.com/flex017/user_avatar/community.ciphermail.com/martijn/32/127_2.png) [@martijn](https://community.ciphermail.com/u/martijn)\ **Post date:** [May 4, 2010, 11:58am UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115/6 "2010-05-04T11:58:13Z")
lst\_hoe02(a)kwsoft.de wrote: > 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. S/MIME uses CMS for digital signatures etc. The timestamp will be stored inside the CMS structure so it should be possible. What I think they mean with not yet supported is that it's not yet an official S/MIME spec. > 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... In principle it is possible to see why the signature failed (failed because the certificate expired or because the message has been tampered). The only real way to solve this is by using a trusted timestamp like you suggested. It would however be nice if the email clients would allow the signature to be validated against the date it was signed. > Any other methods available to get around the problem of "ageing" client > signatures?? That depends on the problem you want to solve. Do you want to check whether it was signed correctly in case of a dispute? For example some sender denies it has sent a message some time ago. Now you need to prove the message was actually sent. Or, do you want to allow all recipients to check the signature after some time? It's is possible to create a simple program that allows you to set the date at which the signature should be checked. This however doesn't work directly from Outlook or Thunderbird. Kind regards, Martijn > **···** > > -- > Djigzo open source email encryption ---
**Author:** ![lst\_hoe021](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lst\_hoe021](https://community.ciphermail.com/u/lst_hoe021)\ **Post date:** [May 4, 2010, 12:57pm UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115/7 "2010-05-04T12:57:15Z")
Zitat von Martijn Brinkers \: > lst\_hoe02(a)kwsoft.de wrote: > > > 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. > > S/MIME uses CMS for digital signatures etc. The timestamp will be stored > inside the CMS structure so it should be possible. What I think they > mean with not yet supported is that it's not yet an official S/MIME spec. > > > 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... > > In principle it is possible to see why the signature failed (failed > because the certificate expired or because the message has been > tampered). The only real way to solve this is by using a trusted > timestamp like you suggested. It would however be nice if the email > clients would allow the signature to be validated against the date it > was signed. > > > Any other methods available to get around the problem of "ageing" client > > signatures?? > > That depends on the problem you want to solve. > > Do you want to check whether it was signed correctly in case of a > dispute? For example some sender denies it has sent a message some time > ago. Now you need to prove the message was actually sent. > > Or, do you want to allow all recipients to check the signature after > some time? > > It's is possible to create a simple program that allows you to set the > date at which the signature should be checked. This however doesn't work > directly from Outlook or Thunderbird. The whole point is: We teach the users to obey valid signatures as additional saftey/assurance. But if the user have a look at the mails in the inbox after some time, many or all of the signed messages pop up with "invalid signature" warnings. This may be logically for technical people, but end-users are scared by such unexpected warnings they don't understand. So if we like to get digital signatures and encryption to be used, they must be user-proof as far as possible. Timestamping when signing would be one piece in the puzzle to prevent unexpected/confusing warnings. Regards Andreas ---
**Author:** ![martijn](https://dub1.discourse-cdn.com/flex017/user_avatar/community.ciphermail.com/martijn/32/127_2.png) [@martijn](https://community.ciphermail.com/u/martijn)\ **Post date:** [May 4, 2010, 4:26pm UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115/8 "2010-05-04T16:26:29Z")
lst\_hoe02(a)kwsoft.de wrote: > The whole point is: We teach the users to obey valid signatures as > additional saftey/assurance. But if the user have a look at the mails in > the inbox after some time, many or all of the signed messages pop up > with "invalid signature" warnings. This may be logically for technical > people, but end-users are scared by such unexpected warnings they don't > understand. So if we like to get digital signatures and encryption to be > used, they must be user-proof as far as possible. Timestamping when > signing would be one piece in the puzzle to prevent unexpected/confusing > warnings. The problem with most S/MIME clients is that they only allow strict PKI usage. It would be better to be pragmatic and explain more than just giving errors. The best advise I can give you is to use certificates that are valid for much longer than 1 year. There is not really a good reason to make a certificate only valid for 1 year (PGP keys for example never expire). Creating certificates and handing out certificates to recipients is always a pain especially if this has to be repeated every year. The problem however is that almost all commercial certificate issuers only create certificates which are valid for 1 year. Even CACert certificates are only valid for 1 year. I will see whether I can convince them to make certificate valid for longer than 1 year (at least 5 years). Kind regards, Martijn Brinkers > **···** > > -- > Djigzo open source email encryption ---
**Author:** ![lst\_hoe021](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lst\_hoe021](https://community.ciphermail.com/u/lst_hoe021)\ **Post date:** [May 4, 2010, 8:53pm UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115/9 "2010-05-04T20:53:25Z")
Zitat von Martijn Brinkers \: > lst\_hoe02(a)kwsoft.de wrote: > > > The whole point is: We teach the users to obey valid signatures as > > additional saftey/assurance. But if the user have a look at the mails in > > the inbox after some time, many or all of the signed messages pop up > > with "invalid signature" warnings. This may be logically for technical > > people, but end-users are scared by such unexpected warnings they don't > > understand. So if we like to get digital signatures and encryption to be > > used, they must be user-proof as far as possible. Timestamping when > > signing would be one piece in the puzzle to prevent unexpected/confusing > > warnings. > > The problem with most S/MIME clients is that they only allow strict PKI > usage. It would be better to be pragmatic and explain more than just > giving errors. > > The best advise I can give you is to use certificates that are valid for > much longer than 1 year. There is not really a good reason to make a > certificate only valid for 1 year (PGP keys for example never expire). > Creating certificates and handing out certificates to recipients is > always a pain especially if this has to be repeated every year. The > problem however is that almost all commercial certificate issuers only > create certificates which are valid for 1 year. Even CACert certificates > are only valid for 1 year. > > I will see whether I can convince them to make certificate valid for > longer than 1 year (at least 5 years). The root-evil of PKI is raising its ugly head.... Once designed as all including directory, and later extended for off-line usage with kludges like revocation-lists and expiring certificates. ☹ You don't get more than 3 year certificates from a CA because the effort for the recommended security and process audits will raise and get really expensive. I was told that the CA must re-audit the certified data if the expiry period is too long for example. It's a pitty that only a few people try hard to get signing/encryption usable. Djigzo is a Tool in the right direction but i think we need more to get S/MIME usable by non-Geeks in large scale. BTW: It seems that Bouncy Castle which is included in Djigzo support RFC 3161 extension. May i ask if you could check how difficult it may be to include something like timestamping in Djigzo? Many Thanks Andreas ---
**Author:** ![martijn](https://dub1.discourse-cdn.com/flex017/user_avatar/community.ciphermail.com/martijn/32/127_2.png) [@martijn](https://community.ciphermail.com/u/martijn)\ **Post date:** [May 5, 2010, 6:39am UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115/10 "2010-05-05T06:39:33Z")
lst\_hoe02(a)kwsoft.de wrote: > The root-evil of PKI is raising its ugly head.... > Once designed as all including directory, and later extended for > off-line usage with kludges like revocation-lists and expiring > certificates. ☹ There is however not really an alternative. PGP keys for example never expire (which is kind of possible with X.509 certificates by making them valid for 100 years). Even though it is possible to sign PGP keys, most PGP keys are not signed. Whether a PGP is trusted should be decided for each individual key. PGP doesn't support a general certificate revocation mechanism (CRLs). You can decide to skip all PKI features, like using never expiring certificates, do not use CRL etc. Then PGP and   S/MIME are kind of similar. Then you have some other proprietary solutions like Voltage IBE but these are only usable for a closed setup. Not that this helps you in any way but if there was a good alternative I would probably have used it. If I would have enough time I would create add-ins for most email clients to be more pragmatic when it comes to PKI rules (in the past I actually created several S/MIME email client add-ons but that was with a different company). Explain more and allow users to override the default PKI behavior. Most S/MIME clients are not built by technicians that didn't think about the end-user. Instead of having the email client doing all PKI checks perhaps the gateway should do it for the end-user. This way the gateway can do more detailed checks and the PKI strictness can be set by the administrator. > It's a pitty that only a few people try hard to get signing/encryption > usable. Djigzo is a Tool in the right direction but i think we need more > to get S/MIME usable by non-Geeks in large scale. True. Like for example a public certificate directory. We also need more pragmatic email clients that allows certain overrides. > BTW: It seems that Bouncy Castle which is included in Djigzo support RFC > 3161 extension. May i ask if you could check how difficult it may be to > include something like timestamping in Djigzo? I'll need some time to look at the documents. If it would be added how are you going to check the signature? Kind regards, Martijn Brinkers > **···** > > -- > Djigzo open source email encryption ---
**Author:** ![lst\_hoe021](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lst\_hoe021](https://community.ciphermail.com/u/lst_hoe021)\ **Post date:** [May 5, 2010, 8:15am UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115/11 "2010-05-05T08:15:41Z")
Zitat von Martijn Brinkers \: > lst\_hoe02(a)kwsoft.de wrote: > > > The root-evil of PKI is raising its ugly head.... > > Once designed as all including directory, and later extended for > > off-line usage with kludges like revocation-lists and expiring > > certificates. ☹ > > There is however not really an alternative. PGP keys for example never > expire (which is kind of possible with X.509 certificates by making them > valid for 100 years). Even though it is possible to sign PGP keys, most > PGP keys are not signed. Whether a PGP is trusted should be decided for > each individual key. PGP doesn't support a general certificate > revocation mechanism (CRLs). You can decide to skip all PKI features, > like using never expiring certificates, do not use CRL etc. Then PGP and >   S/MIME are kind of similar. Then you have some other proprietary > solutions like Voltage IBE but these are only usable for a closed setup. > > Not that this helps you in any way but if there was a good alternative I > would probably have used it. No offense intended... The solution with S/MIME at gateway level is the most usable way i have found until now, that's why we are using Djigzo after all 😉 But the usability for end-users will be the key point for propagation of encryption and yes i'm totaly aware that no idiot-proof \*and\* secure system is possible, but we should try hard to get close. > If I would have enough time I would create add-ins for most email > clients to be more pragmatic when it comes to PKI rules (in the past I > actually created several S/MIME email client add-ons but that was with a > different company). Explain more and allow users to override the default > PKI behavior. Most S/MIME clients are not built by technicians that > didn't think about the end-user. The problem is that the crypto part is not one of the top priorities by the mailclient designers. If have read a discussion lately where one of the maintainer of Thunderbird explained that the crypto part is mostly stuck after 1999 development ☹ The crypto part of Outlook is confusing at least... > Instead of having the email client doing all PKI checks perhaps the > gateway should do it for the end-user. This way the gateway can do more > detailed checks and the PKI strictness can be set by the administrator. With this the problem is how to get the "trust" from the gateway to the client. After all the most important part is to inform the user in clear way what the status of a message is. > > It's a pitty that only a few people try hard to get signing/encryption > > usable. Djigzo is a Tool in the right direction but i think we need more > > to get S/MIME usable by non-Geeks in large scale. > > True. Like for example a public certificate directory. We also need more > pragmatic email clients that allows certain overrides. > > > BTW: It seems that Bouncy Castle which is included in Djigzo support RFC > > 3161 extension. May i ask if you could check how difficult it may be to > > include something like timestamping in Djigzo? > > I'll need some time to look at the documents. If it would be added how > are you going to check the signature? It is more of a future plan. If it is there, it may be easier to convince the mailclient designer to check it. It was simply a idea to get a chicken out of the door so sometime in the future the egg will follow 😉 If it don't confuse S/MIME clients not supporting it, no harm is done but we are ready if someday the timestamp check is integrated at the clients. Many Thanks Andreas ---
**Author:** ![Christine](https://avatars.discourse-cdn.com/v4/letter/c/8491ac/32.png) [@Christine](https://community.ciphermail.com/u/Christine)\ **Post date:** [May 5, 2010, 10:20am UTC](https://community.ciphermail.com/t/timestamp-support-for-e-mail-signing/115/12 "2010-05-05T10:20:26Z")
Martijn Brinkers wrote: > If I would have enough time I would create add-ins for most email > clients to be more pragmatic when it comes to PKI rules (in the past I > actually created several S/MIME email client add-ons but that was with a > different company). Now that would be nice, but as you know, it's a lot of work, not primarily for the technical difficulties, but it's hard to make a plugin for a mail client that works mostly without user interference and still gives a user control over the technology. Maybe if you'd have client plugins for iPhone and Android, as you have for BlackBerry, people would start asking for desktop mail client support. I could work on Android support, but only if there's a market. dagdag Christine > **···** > > -- > dagdag is just a two-character rotation of byebye.