Subject: RE: Inclusion of a Status code within a TSAToken

From: Sarbari Gupta <[email-masked]>
Date: Wed, 2 Jun 1999 15:42:14 -0400

> > The status code is relevant only to the protocol between 
> the TSA client
> > and the TSA. The TSA Token, on the other hand, has a much longer
> > life-span and may be processed by many, many, other 
> entities. I would
> > strongly recommend that the status info not be included  
> the TSA Token.
> > 
> I would tend to disagree with this statement.  Remember that 
> these tokens
> will be used to support non-repudiation and may end up being used as
> evidence in some dispute resolution process.  Therefore, it does seem
> reasonable that some environments may require more than just 
> "the absence of
> an error code means that this is a valid timestamp".  They 
> may require a
> more explicit "this is a valid token" statement from the TSA. 
>  This is what
> the presence of a value 0 (granted) provides in the present 
> token structure.

I don't get it. Are you saying that a valid signed TSAToken does not in
itself constitute a valid timestamp? You need an additional field with
value zero (0) within the token indicating that it's a valid token? Why
is a TSA signing an invalid TSAToken in the first place? Are you
envisioning non-zero status within otherwise valid TSATokens? If so, you
are contradicting a previous statement you made:

>>If an error is
>>present, the response is an error message, not a valid token.  If no
error
>>is present, a status code indicating that a valid token was produced
does
>>appear within the token. 

However, I think I have made my case for excluding the Status info from
the TSAToken. If there is anyone else on this list who has strong
feelings on this issue, let them speak up. Otherwise, continue on with
the current protocol definitions. 

Best regards, 

- Sarbari

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 04 Jun 1999 11:39:44 +0200

Sarbari,

I have been away from my desk only two days and I see that the discussion is
still on going with Robert.

I agree with your nice analysis about denial of service attacks which shows
that signed errors add nothing: nothing can stop denial of service. I would
like to close that discussion which has already taken too long and for this
effect to add one final argument:

We need to be consistent within the PKIX WG: this means that we should
address similar problems in different documents in the same way.

The OCSP standard is addressing the problem the following way :

"  In case of errors, the OCSP Responder may return an error message.
   These messages are not signed. "

The Proposol for the LAAP protocol (Limited AC Acquisition Protocol) is
proposing in  <draft-ietf-pkix-ac509prof-00.txt>

   LACResponseMessage ::= CHOICE {
        ac        [0]  AttributeCertificate,
        errorInfo [1]  ErrorMsgContent -- from [CMP]
   }

I see no reason why TSP should behave differently. In all cases a signed
response is given back when the request was well-formed and an unsigned
status is given back on the contrary.

I hope we can all agree on this and change the current draft accordingly. I
do know that Robert is favoring signed status but I hope that he can
(reluctantly) accept the final argument.

Regards,

Denis