RE: Time-stamp issue

Michael Zolotarev <michael.zolotarev@baltimore.com> Thu, 15 March 2001 10:15 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27987 for <pkix-archive@odin.ietf.org>; Thu, 15 Mar 2001 05:15:54 -0500 (EST)
Received: from localhost (daemon@localhost) by above.proper.com (8.9.3/8.9.3) with SMTP id CAA14600; Thu, 15 Mar 2001 02:15:14 -0800 (PST)
Received: by mail.imc.org (bulk_mailer v1.12); Thu, 15 Mar 2001 02:15:10 -0800
Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA14564 for <ietf-pkix@imc.org>; Thu, 15 Mar 2001 02:15:08 -0800 (PST)
Received: from sweepau.baltimore.com.au (sweepau.zergo.com.au [10.61.2.6]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id UAA07751 for <ietf-pkix@imc.org>; Thu, 15 Mar 2001 20:24:34 +1100
Received: from sydneymail1.zergo.com.au (unverified) by sweepau.baltimore.com.au (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5250903e8e0a3d0206124@sweepau.baltimore.com.au>; Thu, 15 Mar 2001 21:15:48 +1100
Received: by sydneymail1.zergo.com.au with Internet Mail Service (5.5.2650.21) id <G8DHF9A7>; Thu, 15 Mar 2001 21:13:10 +1100
Message-ID: <D44EACB40164D311BEF00090274EDCCA011CFF2F@sydneymail1.zergo.com.au>
From: Michael Zolotarev <michael.zolotarev@baltimore.com>
To: Prashant Dambe <prashant@elock.co.in>, ietf-pkix@imc.org
Subject: RE: Time-stamp issue
Date: Thu, 15 Mar 2001 21:13:07 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AD38.87FAAC60"
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe

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:prashant@elock.co.in]
Sent: Thursday, 15 March 2001 20:26
To: ietf-pkix@imc.org
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.