Re: Inclusion of a Status code within a TSAToken

[thayes@xxxxxxxxxxxx (Terry Hayes)]

Robert Zuccherato wrote:

> Sarbari;
>
> > 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.

The token itself should be the "this is a valid token" statement.  It is a
SignedData object, it has the proper content type OID, and is signed correctly
by a valid TSA.  There is no need for an additional status field in the token.

>
> > [ Error structure removed ]
> >
> The problem is that within your error structure you only have the status and
> nonce.  However, the TSA's policy information should also be included.  It
> may be helpful to have the TSA's name (see discussion of this topic in
> another thread).  For some error codes (e.g. tdaNotAvailable), the time
> would probably be a useful field to include, depending on policy.  If a
> nonce has not been used to link the request and response, then the
> messageImprint field must be present to do so.  The tsaFreeData field would
> probably be useful to some TSA's in the error response.  We probably also
> want to include the version, in case the format changes.  This accounts for
> all of the fields in the token except for tdaTokens and serialNumber, which
> are OPTIONAL.  Therefore, even if we used your proposal, we would end up
> with a structure that looked almost exactly like the present token.  Does it
> really make sense to define a separate structure for an error response with
> almost exactly the same fields as for a valid token?  I don't think so.

I disagree that all these fields are necessary (or even desirable).

Policy - I see no need for a policy identifier.  A policy would be useful if
there could be significant variation in the interpretation of the message.  In
that case the policy indicates what the signer intended the message to mean
within the framework of the protocol.  I don't see why we need to allow any
variation in the error response.

TSA Name - If the error response itself is signed, there is plenty of
opportunity to put the name of the TSA in the SignerInfo field.

time - I don't see why the current time would be useful in a message that
indicates an error occured.  The operation failed, we shouldn't provide partial
results unless they might be useful in future exchanges with the TSA.

serialNumber and tdaTokens - you say they are OPTIONAL.  I say that's a
problem.  These fields shouldn't be allowed in the error responses.  It's better
to leave them out of the definition of the response data type.

message imprint - you are correct here.  If the initial request had a message
imprint, it would be useful to put it in the response to allow the client to
match the two parts of the exchange.

In summary - we need message imprint and/or nonce along with the error code.
That's it.