RE: Inclusion of a Status code within a TSAToken

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> > > 
> > 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.
To be or not to be is a binary value. The presence of a PKIStatus
with granted and no other information is not necessary, it should
be the default. 


> 
> 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:
The TSA is not signing an INVLID TSAToken. First, to nit-pick, it is
signing a TSTInfo (The signed object is a TSAToken.) 

It might be useful to have a VALID Token (granted) with whatever kind
of free form message (someone might want to include a commercial text
in there in order to finance the service.) :-) 

> 
> >>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. 
The proposals are technically equivalent. This seems a matter of taste
to distinguish two things either by an OID, or by a number (The PKIStatus).

On the other hand it seems interesting to me to regard the protocol
and the data structure from a DCS standpoint. It would be nice to
have a common data structure, and the absence of most values would
just indicate time stamping (or as it is said in the DCS text, DCS
is an extension of time stamping.)