Subject: RE: Time-stamp issue

From: Michael Zolotarev <[email-masked]>
Date: Thu, 15 Mar 2001 21:13:07 +1100

Prashant,
 
A signature may also contain the CMS signingTime attribute, which is defined
as an authenticated attribute. if a signer adds the SigningTime attribute to
the signature, and then attaches a timestamp, the time in the timestamp must
be close enough to the time specified by the attribute. All assuming that a
timestamp is obtained soon after signing, of course.
 
Therefore, replacing a 'correct' timestamp with the one generated later in
the future, will be easily detectable.
 
But in general, I dont' think that the threat is there at all:
 
A timestamp can be attached to the signature by either the signer or by a
verifier. Why would the signer want to twick his own signature? I dont'
think he would. Now, the verifier: the verifier attaches a timestamp as an
evidence of his own verification process - "I have obtained and verified
that signature at that time, and the signature was valid". What would be a
reason for the verifier to play with his own evidence? I don't see any
practical reason for it.
 
Regards
Michael

-----Original Message-----
From: Prashant Dambe [mailto:[email-masked]]
Sent: Thursday, 15 March 2001 20:26
To: [email-masked]
Subject: Time-stamp issue

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 ther
evocation 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.

This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

---

From: Michael Zolotarev <[email-masked]>
Date: Thu, 15 Mar 2001 23:37:58 +1100

Folks,

As I have noted in my previous email, the substitution of the timestamp
makes no sence for neither the signer, no the verifier, as presumably both
of them are keen to preserve NR qualities of the signature and corresponding
verification process.

It leaves us with the Man-in-the-middle and an attacker modifying the
signature/timestamp when it is kept in some local storage. As for the M-i-M
(a timestamp replaced when the signature was in transit), the attack will be
instantly obvious by comparing the dates. Not to mention that the signature
must be sent much later after it has been originally created, in order for
the attacker to be able to obtain newer timestamp.

For the local storage case, I think it leaves it up to the owner of the
signature with attached timestamp how to protect it from been maliciously
modified.

Michael

> Sent: Thursday, 15 March 2001 22:53
> To: Joerg Seidel
> Cc: [email-masked]
> Subject: Re: Time-stamp issue
> 
> 
> 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,
> 
> Prashant Dambe wrote:
> > 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.
> 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
> __________________________________________________________________
> 
> 
>