Subject: RE: question to time stamp draft: case of error

From: [email-masked]
Date: Mon, 15 Jan 2001 12:31:17 -0500

Jean-Marc Desperrier ([email-masked]) asked a similar
question in December and Ari Kermaier ([email-masked]) 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?

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.

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: Bernd Matthes [mailto:[email-masked]]
Sent: Monday, January 15, 2001 7:33 AM
To: ietf pkix
Subject: question to time stamp draft: case of error

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: Bernd Matthes <[email-masked]>
Date: Tue, 16 Jan 2001 17:22:06 +0100

> [email-masked] wrote:
> 
> Jean-Marc Desperrier ([email-masked]) asked a
> similar question in December and Ari Kermaier ([email-masked]) wrote:
> 
> > includes systemFailure(25) which, while not very descriptive, might
> fit the
> Denis, will you be adding systemFailure(25) to the PKIFailureInfo in
> the RFC version of the Time Stamping Protocol?

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

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?
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."
> 
> 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

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 22 Jan 2001 12:46:36 +0100

Bernd,

> > the RFC version of the Time Stamping Protocol?

systemFailure(25) has been added.

> I think, if a time stamp query contains a wrong nonce, this is also a

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 ? 

> Is it generally planned that the new RFC provides a signed time stamp

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.

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