Re: question to time stamp draft: case of error

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Bernd,

> > FRousseau@xxxxxxxxxxxxxxxxx wrote:
> >
> > Jean-Marc Desperrier (jean-marc.desperrier@xxxxxxxxxxxx) asked a
> > similar question in December and Ari Kermaier (arik@xxxxxxxxx) wrote:
> >
> > > The PKIFailureInfo structure described in
> > draft-ietf-pkix-rfc2510bis-02
> > > includes systemFailure(25) which, while not very descriptive, might
> > fit the
> > > bill for hardware failure.
> >
> > Denis, will you be adding systemFailure(25) to the PKIFailureInfo in
> > the RFC version of the Time Stamping Protocol?

systemFailure(25) has been added.

> And additional badSenderNonce(18)?
> I think, if a time stamp query contains a wrong nonce, this is also a
> helpful value.

This has not been added. I do not want to raise at this time questions like:
what is a bad nonce ? or how does a server know it is a bad nonce ? 

> BTW,
> if a signed ts query is received, it should be possible to send
> appropriate
> errors send back  like badMessageCheck(1), signerNotTrusted(20) or
> notAuthorized(23).
> Is it generally planned that the new RFC provides a signed time stamp
> query?

There is no plan for a new RFC addressing a signed time stamp query. The
architecture is transport independent. Since the proposed additional error
cases would correspond to the transport protocol, they have not been added.
A revised version, including changes to address comments from Jeff Schiller
(our security area Director) is on its way.

> The last draft-ietf-pkix-time-stamp-12.txt say nothing about this fact.
> 
> >
> > I agree with Jean-Marc and Ari that it would be very useful to add
> > this additional value to the PKIFailureInfo since the latest time
> > stamping draft currently indicates that:
> >
> > "These are the only values of PKIFailureInfo that are supported.
> > Compliant servers MUST NOT produce any other values. Compliant clients
> > MAY ignore any other values."

This text has been changed in the revised document. Wait for the summary of
all the changes that will be posted soon, to see the replacement which
addresses this concern.

Denis  

> > By not adding during the final editing of the RFC
> > version, this useful value could not ever be used to indicate this
> > type of error.
> >
> 
> with kind regards
> --
> Mors certa, hora incerta. In dubio pro mille.
> --------------------------------------------------------------------
> Bernd Matthes                   Celo Communications GmbH
> Senior Software Engineer        Weissenfelser Strasse 46a
> Nachrichtentechniker            D 06217 Merseburg
> Dipl.-Ing.(FH)                  http://www.celocom.com
>   f. technische Informatik      mailto:mainbug@xxxxxxxxxx
> http://www.worldbug.de          Tel.: +49 3461/3318-0
> mailto:mainbug@xxxxxxxxxxx      Fax:  +49 3461/415072
> --------------------------------------------------------------------
> "When in doubt, use brute force." (Ken Thompson)