Subject: question to time stamp draft: case of error

From: Bernd Matthes <[email-masked]>
Date: Mon, 15 Jan 2001 13:33:15 +0100

Hi to all!

If a time stamp token (TimeStampToken) can not produced by a server
due to an internal error, i.e. malloc() failed, which value of PKIStatus
and/or PKIFailureInfo is appropriate to send back to the client?
Or should the client get a profane "Server Error"?

Thanks in advance.
-- 
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:[email-masked]   
http://www.worldbug.de          Tel.: +49 3461/3318-0       
mailto:[email-masked]      Fax:  +49 3461/415072
--------------------------------------------------------------------
"When in doubt, use brute force." (Ken Thompson)

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 15 Jan 2001 20:05:35 +0100 (MET)

> > bill for hardware failure.
> 
> Denis, will you be adding systemFailure(25) to the PKIFailureInfo in the RFC
> version of the Time Stamping Protocol?

With the new text of rfc2510bis one could also have
systemUnavail(24) as a more general error case then
timeNotavailable(14) which in fact is somewhat detailed,
a user doesn't really care about the difference between them.

What is not said in TSP and also not in rfc 2510bis is
the supposed treatment. can a tsp client just retry, 
or is this out of scope of the document? 

> 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."
> 
> By not adding systemFailure(25) during the final editing of the RFC version,
> this useful value could not ever be used to indicate this type of error.
> 
Not quite true, because this can be changed in the next round of
the standards process. 

PS