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

[Manuel Heras Gilsanz <mherasg@xxxxxxx>]

Robert,

what you propose would seem a very reasonable solution to deal with an
*existing*, closed protocol that one would wish to stretch (via "syntax
abuse"), but in my opinion such a proliferation of OIDs should not be
enforced (or strongly promoted) from the very standard definition.

Regards,

     - Manuel -


Robert Zuccherato wrote:

> Manuel;
>
> This is presently supported.  Since a MessageImprint is a hashAlgorithm
> (AlgorithmIdentifier) followed by the hashedMessage (an OCTET STRING) all
> you have to do is define an AlgorithmIdentifier which means "the SHA-1 hash
> concatenated with the MD5 hash" for example and then include the SHA-1 hash
> of the message concatenated with the MD5 hash in the hashedMessage field.
>
>         Robert.
>
> > ----------
> > From:         Manuel Heras Gilsanz[SMTP:mherasg@nexo.es]
> > Sent:         Thursday, April 08, 1999 4:45 PM
> > To:   ietf-pkix@imc.org; afd@fnmt.es
> > Subject:      Time-Stamp: Why not use several hashes?
> >
> > Hi.
> >
> > In the (now expired) latest PKIX draft on time-stamping protocols from
> > Sept. 23, 1998, time-stamp requests and tokens support the insertion of
> > a single message imprint.
> >
> > I think several message imprints should be supported. If a hash
> > algorithm were broken, time-stamp tokens using it (as the single message
> > imprint) would have to be regarded invalid (even if some kind of linking
> > mechanism were implemented!). If several hashes had been used, the token
> > would still be valid, and it could be promptly renewed in order to
> > prevent invalidation should further advances in cryptography render
> > other hashes obsolete!
> >
> > (One must be careful here: there are different extents to which a hash
> > algorithm could be broken; in Appendix A of  PKITS-D3
> > [http://www.fnmt.es/pkits] there is an interesting analysis of the
> > implications that the different kinds of hash failures would have on the
> > time-stamping process.)
> >
> > Of course the requirements on the time-stamp verification process would
> > also have be modified to require ("MUST" level) *all* the hashes to
> > correctly verify in order to regard the corresponding time-stamp token
> > valid.
> >
> > Best regards,
> >
> >     - Manuel -
> >
> > ----
> > Manuel Heras-Gilsanz (mherasg@nexo.es)
> > Independent Security Consultant
> > Phone: +34-629 07 53 31
> >