RE: Inclusion of a Status code within a TSAToken

[Sarbari Gupta <sgupta@xxxxxxxxxxxx>]

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