Subject: RE: Time stamp request

From: Robert Zuccherato <[email-masked]>
Date: Wed, 25 Nov 1998 09:33:13 -0500

Andrew;

In your response to Denis you said:

> ----------
> From: 	Andrew Probert[SMTP:[email-masked]]
> Sent: 	Tuesday, November 24, 1998 5:53 PM
> To: 	'Denis Pinkas'; Carmen Garcia
> Cc: 	[email-masked]; [email-masked]
> Subject: 	RE: 
> 
> This standard seems to be restricting capability based upon a bandwidth
> assumption.  With the right business case, the bandwith may well be
> available?
> 
Actually, I don't think we are restricting capability based upon a bandwidth
assumption.  I would like to draw your attention to something Denis said.

> > Another advantage is that the TSA does not see the
> > content of the message and it cannot disclose the content to anybody:
> > it places less trust in the TSA. For, at least,
> > theses reasons, the message itself is never sent to the TSA.
> 
And also to one of our assumptions in the TSA draft:

The TSA is required:
     3. not to examine the imprint being time stamped in any way. 

In order to distinguish between a Time Stamp Authority and a "notary" (or
what we have called a Data Certification Server in our draft), we had to
make some assumptions about what the TSA can and can't do.  We assumed that
the TSA would not be allowed to examine at all what it is time stamping.

It is unreasonable to expect the TSA to include the entire document within
the time stamp token.  It will only include a hash (or equivalently, a
message imprint).  Given our assumption above, the TSA would then have to
hash any message that is contained in the request, regardless of its content
(because it cannot examine the message in any way) and place the resulting
imprint in the token.  However, if the request already contained just a
message imprint, the token would contain the hash of a hash of the document.
This is not a problem, except for the fact that given just the document and
the token one could not verify that the token applies to the document
without additional information identifying which hash function was used to
create the original imprint in the request.  Since we considered it
important that a token be self-contained, we thought this was unacceptable.
Therefore, we decided that the TSA would not create the message imprint, the
requester would.  This allows the TSA to be totally unaware of what is being
time stamped.  Plus, there are all the other advantages that Denis
mentioned.

	Robert Zuccherato.

---

From: Sarbari Gupta <[email-masked]>
Date: Wed, 25 Nov 1998 11:23:15 -0500

We have built a TimeStamping Authority for a client of ours. This TSA
has been undergoing field trials and tests since June, 1998 and is now
relatively stable. I would like to share our experiences on the topic of
hash versus entire message.

We built the first version of our TSA by having the entire message sent
to the TSA. The TSA computed the hash of the message and created the
token and signed it. In looking at the problem more carefully, we
realized that sending the entire message has several drawbacks, e.g. the
bandwidth availability problem, and the liability problem for the TSA
since it now has a copy of the actual message, etc. In later versions of
our product, we are sending just the hash of the message to the TSA,
since it has all of the advantages, without many of the disadvantages,
of sending the entire message. 

In general, I would agree with Denis, Paul and Robert that there appears
to be no benefit to sending the entire message instead of an imprint of
the message. 

On the other hand, currently (in draft-ietf-pkix-time-stamp-00.txt), the
MessageImprint data structure seems to imply that only a cryptographic
hash of the message is permitted. However, it would be relatively easy
to accommodate other types of message imprints, including the actual
message (there is no better imprint of a message than the message
itself!!) and arithmetic checksums, etc. 

- Sarbari Gupta
=================================
Sarbari Gupta, PhD
CygnaCom Solutions
(703)848-0883 (voice)
(703)848-0960(FAX)
[email-masked]
=================================
-----Original Message-----
From: Robert Zuccherato [mailto:[email-masked]]
Sent: Wednesday, November 25, 1998 9:33 AM
To: 'Denis Pinkas'; Carmen Garcia; 'Andrew Probert'
Cc: [email-masked]; [email-masked]
Subject: RE: Time stamp request

Andrew;

Actually, I don't think we are restricting capability based upon a
bandwidth
assumption.  I would like to draw your attention to something Denis
said.

The TSA is required:

In order to distinguish between a Time Stamp Authority and a "notary"
(or
what we have called a Data Certification Server in our draft), we had to
make some assumptions about what the TSA can and can't do.  We assumed
that
the TSA would not be allowed to examine at all what it is time stamping.

It is unreasonable to expect the TSA to include the entire document
within
the time stamp token.  It will only include a hash (or equivalently, a
message imprint).  Given our assumption above, the TSA would then have
to
hash any message that is contained in the request, regardless of its
content
(because it cannot examine the message in any way) and place the
resulting
imprint in the token.  However, if the request already contained just a
message imprint, the token would contain the hash of a hash of the
document.
This is not a problem, except for the fact that given just the document
and
the token one could not verify that the token applies to the document
without additional information identifying which hash function was used
to
create the original imprint in the request.  Since we considered it
important that a token be self-contained, we thought this was
unacceptable.
Therefore, we decided that the TSA would not create the message imprint,
the
requester would.  This allows the TSA to be totally unaware of what is
being
time stamped.  Plus, there are all the other advantages that Denis
mentioned.

	Robert Zuccherato.

---

From: Andrew Probert <[email-masked]>
Date: Thu, 26 Nov 1998 09:46:07 +1100

I was thing thinking Notary when I wrote my comment, and a combined
standard for both purposed, thanks for clarifying the context.

Andew Probert
Rotek Consulting 
a Division of Secure Network Services
+61 3 9690 8877