Subject: Re: Timestamp: 03: TSP version 3

From: Denis Pinkas <[email-masked]>
Date: Wed, 13 Oct 1999 12:24:36 +0100

James,

It has been long since you posted these comments. :-( Since I am now
in the process of revising the document and publish a new version
before the dead line, here are my answers:

> > Comments on version 3 of the timestamp draft:
> >
> > 2.2
> > Highlights from the 1st sentence: ".. requesting .. requests .. request
> > ..Req ..".  :-)

Any better proposal ? :-) 

> > 2.4.1
> > Please use integer 1 for version 1 - it avoids confusion.
> >       version INTEGER {v1(1)},

OK. 

> > 4) ..TSA offers no guarantee about the strength of the hash functions..
> > But the paragraph after the MessageImprint definition still says 'It is up
> > to the TSA to decide whether or not the given has algorithm is
> > "sufficient"'.  

Ooops ! I forgot to delete that one. Good catch.

> > Rename the 'messageImprint' field as 'opaque' to make it
> > obvious that the TSA is making no claim about the value, other than its
> > existence, even though it is signing it.
> >       opaque  [2] MessageImprint,
> > Why is it optional?

I do not think renaming it is necessary. Since the field is now
mandatory, I will change SHOULD by SHALL in the text.

> > 2.4.2
> > Why repeat selected definitions from CMS (SignedData etc.)?  You still
> > have to read CMS because not all definitions are repeated (e.g.
> > CMSVersion).  Don't bother repeating any - it just opens the possibility
> > of incompatibility or confusion.

It helps the reading anyway.

> > Time is the whole reason for the timestamp.  Call the field 'time', not
> > 'genTime'; put it at the top of the token (after the version) and don't
> > bury it in a TSTTime construct (make 'accuracy' the 3rd field in TSTInfo).
> > Now the major items are directly visible in the definition of the major
> > type.

I will change the ordering to place all mandatory fields first
followed by optional fields and will suppress the TSTTime construct
as you suggest.

> > Don't restrict the 'seconds' accuracy field to 1..59.  This is an
> > unnecessary & arbitrary limit.  My clock may only be synchronized to UTC
> > to +/-2 minutes (I may wish to use a very conservative estimate).  You
> > don't, of course, need a new 'minutes' choice in the Accuracy type, just
> > allow values like 120 seconds.

OK.

> > Show the syntax as: YYYYMMDDhhmmss[.s...]Z
> > This implies all the DER-encoding rules it can (keep the sentence about
> > omitting trailing 0's in the fractional second component & the decimal
> > point if the fractional seconds is 0).
> > The syntax in the current draft does not show the full options of the
> > GeneralizedTime syntax (e.g. does not show decimal comma option), nor does
> > it imply all the DER-encoding restrictions (e.g. terminate with Z).
> >
> > 3.2
> > time-to-check-back
> > Surely a relative time would be far more appropriate here, i.e. number of
> > seconds from now until you should poll again.

This is part of an issue that I am currently discussing with the
co-editors.

> > 3.4
> > How about an easier HTTP request:
> >
> > http://aaa.bbb.com/cgi-bin/timestamp?alg=sha1&hash=A9993E364706816ABA3E257
> > 17850C26C9CD0D89D

 ... but this would mean that we are no more transport independent.
:-(

> >
> > 6.
> > CMS has been published as RFC 2630.

OK.

> > A.
> > Providing a syntax to hold a timestamp & its associated data is a good
> > idea, but there is no need for this to have extra security - the timestamp
> > is already signed & contains a hash of the data!

I personally agree.

> > Given that a major identified use of timestamps is to timestamp a digital
> > signature it is likely that a CMS SignedData structure is already being
> > used.  A sensible place to store a timestamp is in this existing structure
> > - as an unauthenticatedAttribute.
> >
> > A timestamp could apply to the content being signed (e.g. PDF doc), the
> > signature on the content or the signature plus the certificates & CRLs.

This is an interesting proposal. In order to keep things simple I
would propose to limit the case to the signature itself only.
Including certificates and CRLs does not always make sense since the
certificates and CRLs that MAY be present in a CMS structure do not
necessarilly reflect a valid certification path. As advertised on
this mailing list, an ETSI draft document on a foramt of an
*electronic* signature is adding two unsigned attributes which may
contain a certification path and revocation information for that
path and it makes sense to time stamp all that information together.
However this would mean defining additional unsigned attributes
which are clearly out of the scope of this document. Hence the
reason to support only one of your proposals. 

> > Perhaps three attributes are required:
> >       timestampedContent      ATTRIBUTE ::= { WITH SYNTAX ContentInfo  ID
> > id-at-??? 1 }
> >               -- msgImprint is the same value as the MessageDigest
> > auth.att. value
> >       timestampedSignature    ATTRIBUTE ::= { WITH SYNTAX ContentInfo  ID
> > id-at-??? 2 }
> >               -- msgImprint is the hash of the encryptedDigest field
> > (DER-encoded)
> >       timestampedCertSig      ATTRIBUTE ::= { WITH SYNTAX ContentInfo  ID
> > id-at-??? 2 }
> >               -- msgImprint is the hash of the concatenation of the
> > certificates, crls &
> >               -- encryptedDigest fields (all DER-encoded)
> >
> > Alternatively, or in addition, define how the data can be stored in the
> > timestamp itself.
> >       "Data can be stored with its associated timestamp as the contents of
> > an octet string held as the value of a attribute of type 'data' in the
> > unauthenticatedAttributes field of the timestamp."

Before I read your proposal I had never thought things this way !
This is quite original and would be a way to keep things together. I
see it as an alternative to the method described in the appendix A.
I would however like to hear some other opinions from the list on
that topic. 

> >
> > x.
> > The I-D ACTION e-mail had an extra sentence at the end of the Annex,
> > compared to the actual draft.
> >       "..(TDA) .. proves in addition that a datum existed before a
> > particular unpredictable event."
> > This should say "after", not "before".

This is now gone.

Thanks for your very valuable comments.

Denis