Subject: Inclusion of a Status code within a TSAToken

From: Sarbari Gupta <[email-masked]>
Date: Wed, 2 Jun 1999 12:40:09 -0400

Robert, 

> > Looking at the problem from another angle, the TSA protocol needs to
> > change in some way to get the status info out of the TSA 
> token. I have
> > seldom seen a design where error codes get packaged into long-term
> > objects - this problem needs to be fixed whether or not the error
> > response gets signed or not. 
> > 
> Error codes are not packaged with long-term objects.  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.  

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.

> But this is so that we do not have 
> to produce
> responses that consist of a signed token inside of another 
> signed object
> which contains the error codes (assuming that the status codes must be
> signed).  

This is not an adequate reason to justify a design decision. It just
implies that we need to think about other possibilities. I had presented
a proposal to achieve exactly this purpose in a previous note. In this
proposal, the TSAToken does not contain status info, but the error
messages were signed. Did you get a chance to review this proposal? I
repeat it (modified slightly to not exclude the nonce from the TSAToken)
here for your convenience.

[modified proposal from my 5/20/99 note]
>>Define TSAResponse as the response from a TSA:
>>
>>TSAResponse ::= CHOICE {
>>	errorInfo		SignedData,  
>>	tokenInfo		TokenInformation}
>>
>>For an error information message (of type SignedData) the eContentType
is defined as:
>>id-ct-TSTerrorInfo	OBJECT IDENTIFIER	 ::= {id-ct 5}
>>
>>and the eContent shall be of the ASN.1 type TSTErrorInfo.
>>
>>TSTErrorInfo ::= SEQUENCE {
>>	status 	PKIStatusInfo,
>>	nonce 	Integer OPTIONAL}
>>
>>TokenInformation is an unsigned data structure as follows.
>>
>>TokenInformation ::= SEQUENCE {
>>	status	PKIStatusInfo,
>>	token 	SignedData }

> Until I see a convincing reason why they should be 
> contained in a
> separate layer, I think we should leave things as they are and keep
> everything simple.

I think I have already presented a convincing reason for why the status
info should be excluded from the TSA token. You need to be able to
justify the presence of every single field in a long-term and broadly
distributed object. The status info field just does not cut the mark.

- Sarbari

> 	Robert.

---

From: "Juan G. de la Vega" <[email-masked]>
Date: Thu, 3 Jun 1999 09:14:21 +0200

All,

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

kind regards,
Juan.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 3 Jun 1999 13:22:30 +0200

> > the presence of a value 0 (granted) provides in the present 
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. 

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

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