RE: Time-Stamp: Why not use several hashes?

[Robert Zuccherato <robert.zuccherato@xxxxxxxxxxx>]

My comments are below.

> ----------
> From: 	Manuel Heras Gilsanz[SMTP:mherasg@nexo.es]
> Sent: 	Wednesday, April 14, 1999 6:39 PM
> To: 	Robert Zuccherato
> Cc: 	Denis Pinkas; 'Jose A. Manas'; ietf-pkix@imc.org; afd@fnmt.es
> Subject: 	Re: Time-Stamp: Why not use several hashes?
> 
> Robert,
> 
> > I think that if a common hash function is broken (for example SHA-1)
> then no
> > signature created within that infrastructure, with that hash function
> can be
> > trusted, including the TSA's.  Thus, I am reluctant to include multiple
> > hashes within the message imprint.  It will not actually help if the
> hash
> > algorithm used to sign the token is broken.  [...]
> 
> I don't agree with you in the importance assigned to the hashes used in
> the request itself and those used in the signatures. I think both hashes
> have unequal impact on the process, for several reasons:
> 
> -The digital signature is not necessarily the single evidence supporting
> the validity of time-stamp tokens; there could exist some form of
> linking, there could be inter-TSA cross-time-stamping, etc., and in
> these cases the weakest point in the architecture is the path from the
> user document to the TSA, i.e., the message imprint(s) provided by the
> user in the time-stamp request. [In fact, reliable time-stamping schemes
> can be devised without resort to digital signatures.]
> 
But in the scheme we describe, the digital signature is the single evidence
supporting the validity of the time stamp tokens.

> -Digital signatures can become obsolete (they will when the certificates
> of the user, the TSA and/or main CA expire), but in time-stamping
> operations time is essential, and TS-tokens should survive to the pass
> of time. If a hash were broken, the digital signatures could be
> re-issued (time is not essential in them), whereas time-stamps using
> this (single) algorithm for imprint generation would have to be
> invalidated.
> 
Well actually if SHA-1, for example, was broken today then every timestamp
signed using SHA-1 would be invalidated.  What is more likely though is that
SHA-1 would be broken over a period of time and people would know that it
was nearing the end of its useful life.  Then tokens signed using SHA-1
should be re-timestamped.  Similarly, if the message imprint was computed
using SHA-1, the message and the token together could be re-timestamped to
show that the message and imprint existed before SHA-1 actually broke.

> -New document imprints cannot be obtained without cooperation from the
> user, whereas additional digital signatures can be provided by the TSA
> independently. Therefore providing support for several message imprints
> in a single request would greatly reduce the need of user intervention,
> and would increase the time between renewals.
> 
Surely you are not suggesting that a TSA would re-issue EVERY timestamp that
it had issued using a particular hash algorithm.  What is more likely is
that the TSA would inform user's that an algorithm was reaching the end of
it's lifetime and advise them to re-timestamp those items which are still
important.  This requires user interaction.


> > Also, as I stated earlier, if
> > certain individuals really want to do this, they can do it by defining a
> new
> > OID.
> 
> 
> In Section 2.1, "Requirements on the TSA" of the current TS PKIX draft,
> point 8 specifies that the OIDs of the hashes provided by the users must
> be analyzed by the TSA in order to check that they are "sufficiently
> secure"; this is a very important and appropriate requirement,
> introduced to prevent the use of potentially weak hashes. According to
> this requirement, users cannot (unilaterally) define new hash OIDs in
> order to aggregate several "normal" hashes into one, since these OIDs
> would be unknown to the TSA, and therefore rejected. Apart from this
> conflict with the requirements on TSA operation, I sincerely believe it
> is much easier to accomodate the multiple-imprints construct within the
> protocol structures, thus avoiding the need of agreeing on a full set of
> OIDs for multiple-hash functions.
> 
I did not mean to imply that a user could unilaterally define a new hash
OID.  A TSA would most likely list in its policy which hash functions were
acceptable to it.  If the TSA felt that this was an important issue, one of
those could be an OID signaling a concatenation of hashes.

	Robert.