Subject: R: 3 Time Stamping issues

From: Santoni Adriano <[email-masked]>
Date: Fri, 2 Apr 1999 10:35:02 +0200

I have a different doubt about the protocol:

the TSTInfo structure includes a status field with PKIStatusInfo syntax. I
understand that the TSA could signal to the requestor (ie the client) the
unavailability of a time source by using the valure 15 (tdaNotAvailable) for
the failInfo field (with syntax PKIFailureInfo) of the TSTInfo status field.
However, if the TSA has no reliable time source available, it should not
issue a time value at all, right? Nontheless, the tstTime field of the
TSTInfo structure is not OPTIONAL. So, it must carry some value, somehow.

The question, then, is: what time value should be put in the (mandatory)
tstTime field when the TSA signals an error?

The same reasoning applies to other error condition which (should) prevent
the TSA from issuing a time indication.

Adriano

> -----Messaggio originale-----
> Da:	Denis Pinkas [SMTP:[email-masked]]
> Inviato:	giovedì 1 aprile 1999 17.59
> A:	IETF-PXIX
> Oggetto:	3 Time Stamping issues
> 
> Since I am a co-editor of the Time Stamping document, I would like
> to give my opinion on the various issues raised on the mailing list.
> 
> 1. There has been a suggestion to possibly improve the resolution to
> microseconds from milliseconds.
> 
> Since the delay in the transmission is at least in the millisecond
> order, having something more precise would give a false degree of
> precision. I would not go under the millisesond.
> 
> 2. There has been a suggestion to possibly add a precision field.
> 
> I do not think this is absolutely necessary. So I am not supportive
> of it since the policy can handle this.
> 
> 3. There has been a suggestion to possibly add a message information
> field.
> 
> I have arguments *against* this idea. I would realy like to keep the
> TSA as much ignorant as possible of the purpose of the Time
> Stamping. If we add that information, the TSA could know "Invoice
> from Alpha company to Delta company". Is
> this way the TSA could learn that the Delta company is doing
> commerce with the Delta company. This may that be a nice point to
> spy. So I am against the inclusion of that aditional information.
> 
> However, ... I understand the concern of the linkeage and I would
> propose an alternative:
> 
> Defining a Time Stamping Token (TST) that would be able to include
> that information. Basically the TST would be the concatenation of
> the "message information field" and of the signed portion of the
> information received. The TST would be constructed locally instead
> of being fully constructed by the TSA. We could define its structure
> in a normative annex.
> 
> Regards,
> 
> Denis

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 2 Apr 1999 12:35:22 +0200

A similar problem exists in dcs. 

And more: 

In dcs  
     dcsReqInfo                DCSReqInfo,
       --MUST be the same value as the dcsReqInfo field in DCSReqData
     messageImprint               MessageImprint,
       --if the data field in DCSReqData is MessageImprint, this
       --MUST contain that same value, otherwise it contains a hash of
       --the data field in DCSReqData using the hash algorithm
       --specified in the digestAlgorithm parameter of SignerInfo in 
       --the data certification token

are not optional, if the responder wants to signal some encoding error
in the request, there is a problem.