Re: Inclusion of a Status code within a TSAToken

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Sarbari,

I have been away from my desk only two days and I see that the discussion is
still on going with Robert.

I agree with your nice analysis about denial of service attacks which shows
that signed errors add nothing: nothing can stop denial of service. I would
like to close that discussion which has already taken too long and for this
effect to add one final argument:

We need to be consistent within the PKIX WG: this means that we should
address similar problems in different documents in the same way.

The OCSP standard is addressing the problem the following way :

"  In case of errors, the OCSP Responder may return an error message.
   These messages are not signed. "

The Proposol for the LAAP protocol (Limited AC Acquisition Protocol) is
proposing in  <draft-ietf-pkix-ac509prof-00.txt>

   LACResponseMessage ::= CHOICE {
        ac        [0]  AttributeCertificate,
        errorInfo [1]  ErrorMsgContent -- from [CMP]
   }

I see no reason why TSP should behave differently. In all cases a signed
response is given back when the request was well-formed and an unsigned
status is given back on the contrary.

I hope we can all agree on this and change the current draft accordingly. I
do know that Robert is favoring signed status but I hope that he can
(reluctantly) accept the final argument.

Regards,

Denis


> > > 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:
>
> >>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.
>
> Best regards,
>
> - Sarbari