Subject: RE: Inclusion of a Status code within a TSAToken

From: Robert Zuccherato <[email-masked]>
Date: Wed, 2 Jun 1999 15:21:10 -0400

Sarbari;

> ----------
> From: 	Sarbari Gupta[SMTP:[email-masked]]
> 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.

---

From: [email-masked] (Terry Hayes)
Date: Wed, 02 Jun 1999 13:30:05 -0700

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

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.

---

From: "Jose A. Manas" <[email-masked]>
Date: Thu, 03 Jun 1999 06:29:24 +0200

Terry Hayes wrote:

For time-stamps ...

> by a valid TSA.  There is no need for an additional status field in the token.

I think there are some cases were warnings might be issued,
without preventing the time-stamp to be granted.
Either these warnings go into free data, or somehow get
a code that fits into the status code.
I prefer a field to encode them.

For error responses ...

> In summary - we need message imprint and/or nonce along with the error code.

Exactly.

Best,
pp

-- --------------------------------------------------------
Prof. Jose A. Manas                     <[email-masked]>
Dpt. Telematica                 http://www.dit.upm.es/~pepe
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33