RE: Question on Time Stamp Protocols

[Rob Zuccherato <robert.zuccherato@xxxxxxxxxxx>]

Olivier;

>----------
>From: 	Onimus@danet.de[SMTP:Onimus@danet.de]
>Sent: 	Thursday, September 11, 1997 2:33 AM
>To: 	ietf-pkix@tandem.com
>Subject: 	Question on Time Stamp Protocols 
>
>I have a very basic question about PKIX Part V Time Stamp Protocols:

Okay, I will try and answer it.  You should be aware though that at the
Munich meeting the group decided that we wouldn't discuss Parts V and VI
until significant progress had been made on Parts I-IV.  So any further
discussion at this point should probably take place offline.
>
>Why must the data to be time-stamped have the form
>
>MessageImprint ::= SEQUENCE { 
>     hashAlgorithm AlgorithmIdentifier,
>     hashedMessage OCTET STRING} 
>
>What is the benefit, that an AlgorithmIdentifier must be specified and the
>data must
>be hashed ?
>
>MessageImprint could have the form: MessageImprint ::= OCTET STRING
>
>In this case, the requesting entity is responsible for the data it transmits.
>The data contained in the OCTET STRING may be the hash of something, or
>the signature of something, or something which was not modify by a
>hash-function. 
>
>The Time Stamping authority may refuse data which are too big or not, and
>would not have
>to decide wether or not the given hash algorithm is "sufficient" !

Let me try to answer all of this at once.  It was considered undesirable
to reproduce the entire document in the Time Stamp Token.  If it was
reproduced, this could possibly cause problems with bandwidth and
storage.  For this reason we decided that only a hash of the message
should appear in the token.  Once you decide this, you are left with the
decision of who should compute the hash, the requester or the TSA.  

If the TSA computes the hash, it should compute the hash for every token
it receives, regardless of if it is already the hash of something, a
signature or anything else, since we do not want the TSA making any sort
of judgments about the message itself.  If the TSA did compute the hash
for every message, it could create some problems.  Let me give an
example to illustrate.  I hash a message, M, using my favourite hash
algorithm h_1 and send h_1(M) to the TSA to be time stamped.  The TSA
now uses it's favourite hash algorithm, h_2 to hash what I send it, and
produces a Time Stamp Token containing h_2(h_1(M)).  Now, in order to
prove the time at which M was supposed to have existed, I provide the
message M and the token containing h_2(h_1(M)).  Well, h_2 would be
indicated in the token, but h_1 won't be (even if it is sent along in
the request, it's OID would be hashed along with h_1(M)).  So, some
additional information is needed to bind M to the token.

If we do it the way we have, the requester computes the hash and sends
that along with the OID in the request.  These two pieces of information
are then copied into the time stamp token.  Now if we are given just M
and the token then the hash value and the algorithm appear in the token
and should bind the message to the token.  This way no additional
information is needed, we save bandwidth and storage, and the TSA
doesn't have to examine the message in any way.  Granted, the TSA does
still have to decide whether or not to accept the hash algorithm, but we
>felt that this was better than the alternatives.
>
>How can the Time Stamping authority check (in the current version),
>that the hash-data were produced by the requesting entity using the specified
>algorithm (and not using another algorithm as the one specified) ?

It can't, and doesn't have to.  But, if the hash algorithm is
"sufficient" (one-way and collision resistant) it should not be possible
to create some other message M' that hashes to the given value.  So, if
I send some random value h and the OID of a "sufficient" hash algorithm
to be time stamped, I will get a perfectly good time stamp token back.
I don't however have a message M' to bind to the token, and finding
would is computationally infeasible.  So, the token is useless.  Also,
if the hash was produced with some other hash algorithm, the OID of the
algorithm specified in the request would appear in the token, and again
since the algorithm is "sufficient", the token would be useless.  

I hope that this helps to clear up any confusion.


	Robert Zuccherato
>
>
>
>