Subject: RE: Comments on PKIX Time Stamp Protocol

From: "Linn, John" <[email-masked]>
Date: Wed, 4 Aug 1999 08:59:58 -0400

I'll agree with Nick here; I think the operation of matching a hash
algorithm OID against the TSA's current list of acceptable algorithms as a
prerequisite for timestamp generation should be a policy-configurable option
rather than an architectural requirement.  Application of timestamps and
determinations of algorithmic strength and appropriateness are distinct
operations, which may not always be coupled appropriately at the same place.

--jl

> -----Original Message-----
> From: Nick Pope [mailto:[email-masked]]
> Sent: Wednesday, August 04, 1999 8:35 AM
> To: Denis Pinkas
> Cc: [email-masked]
> Subject: RE: Comments on PKIX Time Stamp Protocol
> 
> 
> Denis,
> 
> What I am suggesting allows the TSA to set up a service which 
> refuses to
> timestamp any algorithm which it doesn't recognise.  So if if 
> this was a
> concern then this policy could be applied.  However, in an 
> open environment
> I believe that it is unnecessarily restrictive to mandate 
> that the TSA has
> to recognise the hashing algorithm.  It gives no flexibility 
> for the use of
> new hashing algorithms.
> 
> Nick
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: 04 August 1999 11:32
> > To: Nick Pope
> > Cc: [email-masked]
> > Subject: Re: Comments on PKIX Time Stamp Protocol
> >
> >
> > Nick,
> >
> > Since there has been many messages sent on the TSTTime format, I
> > missed that message. Sorry for the delay to respond.
> >
> > > Comments on PKIX Time Stamp Protocol
> > > draft-ietf-pkix-time-stamp-02.txt
> > >
> > > I have been working on an ETSI electronic signature standard
> > which makes use
> > > of time-stamping and as a result would like to offer the a few
> > comments on
> > > the document:
> > >
> > > 1) Section 2.4 mandates that the Hash Algorithm is provided by
> > the client
> > > and has to be approved by the server.
> > >
> > > This protocol can't be used if the client has its own, 
> perfectly good,
> > > hashing algorithm which isn't known to the time-stamping server.
> >
> > This is a correct interpretation from the correct text.
> >
> >
> > > The current text already only states that the  hashedMessage
> > field "SHOULD
> > > contain the hash", but the length of this field "MUST match the
> > length of
> > > the hash value for that algorithm".
> >
> > Good catch. We should say "when present, the hashedMessage field
> > SHALL contain the hash".
> >
> >
> > > The current protocol encourages the client to lie about the
> > hash algorithm
> > > employed !
> >
> > With the modification above, I do not think so.
> >
> >
> > > I therefore suggest that the definition of MessageImprint 
> is changed as
> > > follows:
> > >
> > > " MessageImprint ::= SEQUENCE  {
> > >      hashAlgorithm                AlgorithmIdentifier  OPTIONAL,
> > >      hashedMessage                OCTET STRING  }
> > >
> >
> > The basic question is whether the TSA will or will not accept to
> > sign if it does not recognize the hash algorithm. From the
> > discussion we had on the list the consensus seems to be that if the
> > TSA knowns a hash algorithm to be weak (which is an appreciation at
> > the discretion of each TSA), the TSA will refuse to sign.
> >
> > Unless we change that point, the ASN1 should not be changed.
> >
> > A further side advantage is that the TSA can verify that the length
> > of the hash value matches the expected length of the hash algorithm.
> >
> >
> > >   The hash algorithm employed to to create the hashedMessage
> > field SHOULD
> > >   be a strong hash algorithm.  That means that it SHOULD 
> be one-way and
> > >   collision resistant.  If the hashAlgorithm is present 
> then the Time
> > >   stamp Authority MUST check whether or not the given 
> hash algorithm is
> > >   known to be "sufficient" (based on the current state of 
> knowledge in
> > >   cryptanalysis and the current state of the art in computational
> > >   resources, for
> > >   example).  The TSA may refuse to time stamp 
> hashedMessage without an
> > >   indication of the hashAlgorithm depending on the 
> security policy.
> > >
> > >   The hashedMessage field SHOULD contain the hash of the 
> datum to be
> > >   time stamped.  The hash is represented as an OCTET 
> STRING.  If  the
> > >   hashAlgorithm field is present the length of the 
> hashedMessage field
> > >   MUST match the length of the hash value for that algorithm (e.g.
> > >   20 bytes for SHA-1 or 16 bytes for MD-5). "
> > >
> > > -------------------------------
> > >
> > > 2) In Appendix A "Storage of Data and Token" it states "the
> > contentType is
> > > signedData and contentInfo is Data, which contains the datum
> > associated with
> > > the time stamp token."  It also goes on to describe a signed
> > attribute to
> > > carry the timestamptoken.
> > >
> > > Surely if the Content Type is signedData the the contentInfo
> > must contain
> > > the CMS SignedData structure.  Also, the SignedData structure
> > is needed to
> > > carry signed attributes.
> > >
> > > Thus, I presume that Appendix A should read:
> > >
> > >   "A time stamp token is meaningless without its 
> associated data. The
> > >   following method can be used to store data and token 
> together securely
> > >   as a PKCS #7 SignedData object as described in [CMS].
> > >
> > >   The contentType is id-signedData and contentInfo is
> > signedData.  Within
> > >   the signedData eContentType is id-data and the eContent 
> contains the
> > >   datum associated with the time stamp token.  The 
> SignedData object is
> > >   signed by the person storing the data and token.
> > >
> > >  ... (unchanged) ...
> > >
> > >   id-aa-timeStampToken     OBJECT IDENTIFIER ::= { id-aa 13 }
> > >   id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }
> > >
> > >   The hashMessage value in the MessageImprint is 
> calculated over the
> > >   datum as held in value of eContent within the signedData."
> >
> > What you say seems reasonable. I would have to take a closer look
> > when I produce the next version.
> >
> >
> > >
> > > -------------------------------
> > >
> > > 3) Finally in 2.4, Page 6:
> > >
> > > id-ct    OBJECT IDENTIFIER ::= { id-smime 1 }
> > > id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> > >             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
> >
> > I will take care of this when I produce the next version.
> >
> > Thanks,
> >
> > Denis
> >
> >
> > > is repeated.
> >
>

---

From: "tog" <[email-masked]>
Date: Wed, 4 Aug 1999 08:18:35 -0700

----- Original Message -----
From: Linn, John <[email-masked]>
To: 'Nick Pope' <[email-masked]>; Denis Pinkas <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 04, 1999 5:59 AM
Subject: RE: Comments on PKIX Time Stamp Protocol

> algorithm OID against the TSA's current list of

'supported' may be a better word than 'acceptable' here.

> acceptable algorithms as a

True!

SNIP