Subject: Comments on PKIX Time Stamp Protocol

From: "Nick Pope" <[email-masked]>
Date: Mon, 2 Aug 1999 12:35:48 +0100

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.

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".

The current protocol encourages the client to lie about the hash algorithm
employed !

I therefore suggest that the definition of MessageImprint is changed as
follows:

" MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier  OPTIONAL,
     hashedMessage                OCTET STRING  }

  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."

-------------------------------

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 }

is repeated.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 04 Aug 1999 12:31:48 +0200

Nick,

Since there has been many messages sent on the TSTTime format, I
missed that message. Sorry for the delay to respond.

> hashing algorithm which isn't known to the time-stamping server.

This is a correct interpretation from the correct text.

> 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

With the modification above, I do not think so.

>      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. 

>   20 bytes for SHA-1 or 16 bytes for MD-5). "

What you say seems reasonable. I would have to take a closer look
when I produce the next version.

I will take care of this when I produce the next version.

Thanks,

Denis

---

From: "Nick Pope" <[email-masked]>
Date: Wed, 4 Aug 1999 13:34:46 +0100

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,
>