Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt

From: Robert Zuccherato <[email-masked]>
Date: Wed, 12 May 1999 13:59:04 -0400

Juan;

As I stated at the time, since this protocol relies on signatures to
preserve the integrity of the time stamp token, and signing algorithms make
use of hashes, if SHA-1 is broken, for example, then no time stamp token
will be trusted.  Thus, adding more hashes will not improve the security of
the protocol.

I am also concerned that TSA's will begin demanding that 3 (or 4 or 5)
different message imprints be included within the request, in order to make
it more "secure".  Or that verifiers will begin to be required to verify
every message imprint (even though you only really need to verify one
imprint).  This will make client tools much more complex.  

Since the benefits of including a SEQUENCE OF Message Imprint are dubious,
there are possibly negative consequences, and there doesn't appear to be a
great deal of support for including it, I left it out.

	Robert.

> ----------
> From: 	Juan G. de la Vega[SMTP:[email-masked]]
> Sent: 	Wednesday, May 12, 1999 7:06 AM
> To: 	[email-masked]
> Subject: 	Re: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
> 
> Hi there,
>  
>     I would like to make use of this new draft announcement to recall an
> old discussion on the messageImprint field which seems not to have been
> solved at sigth of this new draft:
>  
>     The question of using a SEQUENCE OF MessageImprint instead of the
> single MessageImprint arised on the basis of strenghtening the relation
> beetwen the digital object to be stamped and the representation of that
> object (i.e. message digests) in a way that beared possible weaknesses in
> one of the hash functions used to obtain that representation.
>     In order to address this without modifying the syntax, the use of
> "composite" OIDs was proposed (i.e. valid OID could be "SHA1++MD5"),
> besides this is not specified in the draft, it doesn´t seem to be a very
> good idea and this is my personal opinion; a structure "SEQUENCE OF" would
> be more appropriate there, not just because the number of OIDs grows
> exponentially (assuming an agreed method for sorting the hashes) with the
> number of hash functions, but for some other reasons:
> 
>  
>     On one hand, the use of a "SEQUENCE OF" would replace the presently
> optional field "messageImprint". There is no need for this new field to be
> declared optional since an "empty sequence" may be used. Therefore this
> becomes a wherewithal to reduce optional fields (I can remember someone
> complained about that).
> 
>  
>     On the other hand this new structure preserves interoperability; TST
> verification software may not understand an agreed "composite OID" in
> which agreement it did not take part (i.e. a verifier trying to validate a
> token issued by some other TSA that agreed a new OID with ITS clients).Not
> understanding the OID it would be unable to process the associated value.
> It seems more natural to me that a client software "scans" a sequence of
> hashes looking for those it knows and trusts...
>  
> bye,
>  
> Juan.
> ____________________________________________
> Juan González-de-la-Vega
> Software Engineer
> e-mail: < [email-masked]>
> FNMT - Fábrica Nacional de Moneda y Timbre
> Phone: +34 (91) 506 48 40.
> Fax: +34 (91) 506 48 59
>

---

From: "Jose A. Manas" <[email-masked]>
Date: Fri, 14 May 1999 08:07:24 +0200

> will be trusted.  Thus, adding more hashes will not improve the security of

I prefer to think of time stamping as a service provided by a TTP.
Part of TTPs value derives from evidence storage for later resolution of
disputes. Since it is a core part of a time-stamping service not to
disclose
data, the only evidence a TSA may hold is the hash value(s). 
Enhancing the "quality" of evidence is achieved by means of several hash
values.
That's true despite the fact that the "time-stamp receipt" returned by
the TSA
might be broken (if a single hash value is used to sign the receipt).

> imprint).  This will make client tools much more complex.

I'd rather say client tools are simpler.
In order to get a time-stamp, as many hash values may be provided as
wished,
and even different TSA (with different practices) may accept a single
request token.
Verification is a separate issue, where the verifier may apply its own
point of view on which hash algorithms are reliable
(in fact, the practice of the verifier may be different from
the practice of the service provider).

> great deal of support for including it, I left it out.

I'd rather say that it is a cheap opportunity to devise a clean
exchange protocol that keeps doors open for actual implementations
to choose as appropiate for their business case.

>         Robert.

Best,
pp

-- --------------------------------------------------------
Prof. Jose A. Manas                     <[email-masked]>
Dpt. Telematica                 http://www.dit.upm.es/~pepe
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33