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

From: Robert Zuccherato <[email-masked]>
Date: Tue, 25 May 1999 13:41:05 -0400

Perhaps I am missing something, but besides a new syntax for the error
message, how is this substantially different than what we have in the
present draft?  (I assume that your second bullet should read "an
authenticated error message", based on your description below.)

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Friday, May 21, 1999 10:12 PM
> To: 	Robert Zuccherato
> Cc: 	'Jose A. Manas'; [email-masked]
> Subject: 	Re: Comments on draft-ietf-pkix-time-stamp-01.txt
> 
> <<File: thayes.vcf>>
> Robert Zuccherato wrote:
> 
> > How can we do this (separate transient data from long-lived data) and
> still
> > 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.
> 
> 
>

---

From: [email-masked] (Terry Hayes)
Date: Tue, 25 May 1999 11:29:31 -0700

Robert,

My response may have been less-than-clear on two points.  First, the modified
protocol does NOT contain an error value in the TimestampToken.  Errors are
limited to the second type of response.  This is very different from the current
draft, which produces data that "looks" like a token, but is not valid since an
error value is set within it.

Second, I intended to describe the changes to the current draft in two phases -
a protocol that returns tokens or UNauthenticated errors, and then a better
protocol that provides authentication for the error values (to prevent
spoofing).  The bullet you refer to is meant to describe the first phase, and is
what I intended.

To expand:  this first phase of changes to the current draft protocol could also
allow the server to quietly discard requests that generate an error.  This might
be an appropriate response when the service is provided over email, or UDP
channels.  This possibility also falls in to the realm of unauthenticated
responses, since there is no verifiable response from the server to indicate the
request was denied.

Also, when the second phase of changes is applied (to add authenticity to the
errors), you can choose to allow (or require) a different certificate to be used
to sign the error values.  This is also different than the current proposal.
I'm not convinced it is necessary since the content-type OID in the SignedData
will clearly indicate the response is not a real time-stamp token, but some
people may feel more comfortable signing with a different key (and certificate)
in this case.

Terry