Timestamp support for e-mail signing

Gateway
1

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

2

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.

3

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

4

Zitat von Martijn Brinkers <martijn(a)djigzo.com>:

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

5

Zitat von Christine <christine(a)christine.nl>:

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 (Verisign) or
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:

6

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

7

Zitat von Martijn Brinkers <martijn(a)djigzo.com>:

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

8

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

9

Zitat von Martijn Brinkers <martijn(a)djigzo.com>:

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. :frowning:

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

10

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. :frowning:

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

11

Zitat von Martijn Brinkers <martijn(a)djigzo.com>:

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. :frowning:

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 :wink:
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 :frowning:

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 :wink:
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

12

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.