Inclusion of a Status code within a TSAToken

[Sarbari Gupta <sgupta@xxxxxxxxxxxx>]

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