RE: Inclusion of a Status code within a TSAToken

[Robert Zuccherato <robert.zuccherato@xxxxxxxxxxx>]

Sarbari;

> ----------
> From: 	Sarbari Gupta[SMTP:sgupta@cygnacom.com]
> Sent: 	Wednesday, June 02, 1999 12:40 PM
> To: 	'Robert Zuccherato'
> Cc: 	PKIX (E-mail)
> Subject: 	Inclusion of a Status code within a TSAToken
>   
> 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.

> > 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 must have missed it among the flood of emails I have been receiving on
this topic.

> I
> repeat it (modified slightly to not exclude the nonce from the TSAToken)
> here for your convenience.
> 
Thank you.

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

	Robert.