Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt

From: Robert Zuccherato <[email-masked]>
Date: Thu, 20 May 1999 11:32:26 -0400

Sarbari;

> ----------
> From: 	Sarbari Gupta[SMTP:[email-masked]]
> Sent: 	Thursday, May 20, 1999 9:24 AM
> To: 	'Jose A. Manas'
> Cc: 	[email-masked]
> Subject: 	RE: Comments on draft-ietf-pkix-time-stamp-01.txt
> 
> Jose,
> 
> You write:
> >We have identified a business case for this service where the TSA
> >does know the contents. The issue is whether it is a time-stamping
> >service any longer or you have jumped into a notary service.
> >If I were not too purist, I think there are situations
> >We have identified a business case for this service where the TSA
> >does know the contents. The issue is whether it is a time-stamping
> >service any longer or you have jumped into a notary service.
> >If I were not too purist, I think there are situations
> >where the time certificate is something more than a separate
> >appendix, for easiness of storage, transmission, verification,
> >and so on.where the time certificate is something more than a separate
> >appendix, for easiness of storage, transmission, verification,
> >and so on.
> 
> I personally don't see why a timestamping standard cares what data is
> allowed to be timestamped. As far as I know, a notary not only vouches
> for the contents, but also vouches for the identity of the parties that
> are signing the document (to be notarized). So, just allowing data to be
> timestamped does not promote it to a notary service, I think.
> 
No, but as soon as the TSA is allowed to examine the data and must change
it's actions based on that data, it is doing more than just providing a
"proof-of-existence".

> >Packaging things in two levels adds complexity, but does not
> >help any practical situation I may foresee. If simplifity
> >is an objective, a single layer is simpler.
> 
> I agree simplicity should be a goal. The two layer SignedData is
> somewhat complex, but there are other ways of separating the transient
> data (status, nonce) from the long-lived timestamp token.
> 
How can we do this (separate transient data from long-lived data) and still
maintain simplicity and security?

	Robert.

---

From: [email-masked] (Terry Hayes)
Date: Fri, 21 May 1999 19:12:11 -0700

> maintain simplicity and security?

I don't think this is too hard to do.  First, define the basic (low-level)
operation of the protocol as a request, followed by one of two responses:

   * a TimestampToken
   * an unauthenticated error message

The error message will need the nonce and/or imprint fields to tie it to the
original request. (I won't define that type here)

You can run the protocol like this (or just not respond for errors).  As you
have pointed out, this is subject to denial-of-service attacks.

So now add another level of protocol that packages sends either the token, or a
signed version of the error message.

     BetterTSAResponse ::= CHOICE {
       [0] tsatoken TimestampToken,
       [1] authenticatedError SignedData
     }

The SignedData will contain a TSAErrorResponse type and you'll need an OID to
indicate that (id-ct-TSTError).  You can adopt the same rules for validating
the signer of this data as you did for TimestampToken (allowing the TSA to sign
its error messages), or you can define different requirements altogether.