Subject: Time-stamp issue

From: "Prashant Dambe" <[email-masked]>
Date: Thu, 15 Mar 2001 14:56:17 +0530

As specified in the draft-ietf-pkix-time-stamp-13.txt.
APPENDIX A - Signature Timestamp attribute using CMS
One of the major use of time stamping is to time stamp a digital signature to prove that the digital signature was created before 
a given time. Should the corresponding public key certificate be revoked this allows to know whether the signature was created before or after the revocation date.
A sensible place to store a time stamp is in a [CMS] structure as an unsigned attribute.

But what happens in the following scenario.
As timestamp token is placed as unsigned attribute, one of the possible attack is that 
if Time-stamp token it self is replaced with the Time-stamp token of the same signature value
inside CMS  i.e  If the same signature is time-stamped after some later time and Time-stamp in the 
original CMS is replaced,it not possibled to detect that orignal time-stamp has been replaced.
So putting time-stamp as unsigned attribute not works fine in all cases.

Thanks
Prashant Dambe.

---

From: Joerg Seidel <[email-masked]>
Date: Thu, 15 Mar 2001 12:27:25 +0100

Prashant,

> So putting time-stamp as unsigned attribute not works fine in all

This is not an attack which leads to false evidence. Even the new
timestamp states correctly that the signature was made before the given
time. Just you destroy some evidence, which is something you always can
do.

Regards
Joerg
-- 
__________________________________________________________________

Jörg Seidel                             phone  +49-40-76629-1911
Director Technology                     fax    +49-40-76629-551
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[email-masked]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________

---

From: "Prashant Dambe" <[email-masked]>
Date: Thu, 15 Mar 2001 17:23:00 +0530

In the time critical situation this will not work. Suppose Time-stamp is
taken at some time t1. At time t1 signer cert
is valid (not revoked / not expired) and after some time t2 original
time-stamp has been replaced with time inside
TS as t2. At at time t2 suppose signer cert is not valid (revoked/expired)
in this case, original evidence which says
that cert is valid at t1 so you can trust the signature and also data at the
time t1. But if Timestamp token is replaced
indicates that revoked certicate can not be used to validate the signature
which is one of purpose of time-stamp.
In this case you can not say wheather time-stamp is trusted or replaced. If
you assume it was valid TS then it
will leads to wrong results. Also vice-versa of above situation is also
possible.
So at least , if the attack is detected it will not lead to wrong results.

----- Original Message -----
From: Joerg Seidel <[email-masked]>
To: Prashant Dambe <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 15, 2001 4:57 PM
Subject: Re: Time-stamp issue

Prashant,

Regards
Joerg

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 15 Mar 2001 12:58:30 +0100

Prashant Dambe wrote:

> But what happens in the following scenario.As timestamp token is
> placed as unsigned attribute, one of the possible attack is thatif
> Time-stamp token it self is replaced with the Time-stamp token of the
> same signature valueinside CMS  i.e If the same signature is
> time-stamped after some later time and Time-stamp in theoriginal CMS
> is replaced,it not possibled to detect that orignal time-stamp has
> been replaced.

[I'm saying the same thing as Joerg, but more explicitly]

-- Yes, this attack would be possible, but in that case anyway you have
a serious problem.
The person that could do that, coud also do a "del *.*" or "rm -r *" on
your data, and getting out any signed message to prove anything would be
difficult for you after that.

If you think it's possible that someone changes data on your local
storage, are not able to avoid this, but still want to see it happened,
you need to sign it once more.

-- A time-stamp proves a data existed at a certain date, but can not
prove anything about how long before that time it started to exist, and
no change in the protocol will modify that.

If you manage to get back the original time-stamp (for example from the
TSA logs), you will have proven your data did exist at that earlier
date.

-- There's no way to change this situation, except signing the data
again, as I already wrote.

I might be wrong , but I believe you think it would be better if the
time-stamp was calculated over the content of the signed message, and
then included as a signed attributes, before signing the message, as it
would provide this intrusion detection feature

But this would not be the time-stamping of the signature of your message
anymore.

Anyone could remove your signature of the message, put his own, and
claim to be the author, keeping your original time-stamp inside the
message.

----------- About Zolotarev's answer :
- Yes, including a CMS signingTime attribute is a good idea, if a good
date is available locally.
There can be cases where none is available, so we can talk about this
cases.

- "the verifier attaches a timestamp as an evidenceof his own
verification process -
"I have obtained and verified that signature at that time, and the
signature was valid".

What are we talking about ? A TSA in the TSP protocol signs a hash and
does no such verification.
Appendix A of TSP does not describe any such verification.

If a TSA does this, it will need to include an extension in the
time-stamp to say it did it, and so that the difference with the
"normal" time-stamps it produces can be made, and it will need also to
define a request protocol to get the full signature message, and not
just the hash in this case.
But we are strongly getting away of the TSP in this case.

The attack by itself is perfectly feasible in TSP.

---

From: Joerg Seidel <[email-masked]>
Date: Thu, 15 Mar 2001 14:43:55 +0100

Prashant,

Prashant Dambe wrote:
> will leads to wrong results.

No, it does not. Because the correct statement is: "I don't know whether
this signature is valid or not.". This is simply, because someone
removed the proof that it was made before expiration time. Adding a
later timestamp doesn't change this situation.

> Also vice-versa of above situation is also
> possible.

As stated above there are no wrong results.

Joerg