RE: Inclusion of a Status code within a TSAToken

["Juan G. de la Vega" <jgonzalez@xxxxxxx>]

All,

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


It is my concern that a signedData structure correctly signed is enough
proof of validity, specially in the case of an Authority (i.e. making
reference to its policy within that structure). There is no need (even of
dubious worth) to have a field specifying "granted" for it does not provide
further information on the service. We might advocate in a different
direction if more values could be provided (e.g. "granted with mods") but
this is not the case.

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


It is my belief that in the interest of keeping the protocol simple and
coherent, using different structures, one for TSATokens and one for
signaling errors, is the cleanest solution. Since the Status info for a
TSAToken structure can be assumed (a single value) it should not be
included. If we agree that authenticated error messages are to be provided,
then a CHOICE within the SignedData Content structure will do.

>
>Best regards,
>
>- Sarbari

kind regards,
Juan.