Subject: Re: 3 Time Stamping issues

From: "Todd S. Glassey" <[email-masked]>
Date: Thu, 1 Apr 1999 16:02:16 -0800

Denis, -

SNIP ---

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

This assumes that you use a SW only model from today's commercially
available equipment at the PC level. Anyone that needs a more reliable or
finer granularity timesource can get a HW module from Datum or any of the
other time board providers. Commercial computing has used IRIG-B and other
timebase distribution protocols in time dependent networking apps for years.

Limiting ourselves to a millisecond is probably ok for the next year or two,
but microseconds are coming so why not use a large enough data structure to
handle these eventualities?

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

No - absolutely there needs to be a precision field for comparison purposes
and as part of the policy control infrastructure.

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

I agree that the current protocol tools are probably ok without the message
information *as long as we do the token strures*

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

Yes, we should have a TST draft to submit on our GeoPositional Token by the
end of the weekend. Stay Tuned.

Todd

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 2 Apr 1999 11:45:05 +0200

It seems to me that we are handling different things:

- A requester of a time stamp may want to have an indication
  somewhere that allows to correlate a response with a request.

  For the actual time stamping proposal I do not see why the
  requester could not simply use the message imprint itself.
  (If the hash is not collision free, the requester already has
  another problem.)

  For the DCS draft there may be a problem because it is the
  DCS server that decides to create a messageImprint from the
  given data, and the current text proposes the DCS responder
  to choose the hash. One might change this and say, that the
  reponder takes (one of) the digest function used during signing
  the request. 

- A requester wants to carry whatever kind of pointer to the real
  data. One might debate about the usage, in any case I am not
  sure whether an opaque octet string is the right solution. 
  The type of the data should probably be indicated by an OID. 

> from Alpha company to Delta company". Is
> this way the TSA could learn that the Delta company is doing

I agree (contrary to what I have said a few hours ago.)  ;-)

> of being fully constructed by the TSA. We could define its structure
The actual Timestamp token is a cms signed data object;
the requester always has the possibility to add an
unsignedattribute to the SignerInfo of the response.

---

From: Robert Zuccherato <[email-masked]>
Date: Mon, 5 Apr 1999 15:37:59 -0400

Adriano;

How about if I add the following text:

When issuing an error response with PKIFailureInfo having value
timeNotAvailable (14) then the TSA MAY place any random value in the tstTime
field of TSTInfo.  Upon receiving such an error response a client MUST not
trust the time contained in the tstTime field.    

This seems like reasonable behaviour.

	Robert.

> ----------
> From: 	Santoni Adriano[SMTP:[email-masked]]
> Sent: 	Friday, April 02, 1999 4:35 AM
> To: 	'Denis Pinkas'; 'Robert Zuccherato'
> Cc: 	IETF-PXIX
> Subject: 	R: 3 Time Stamping issues
> 
> 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.
> > 
> > Regards,
> > Denis

---

From: "Todd S. Glassey" <[email-masked]>
Date: Mon, 5 Apr 1999 20:11:44 -0700

SNIP ---

--> Why Not force a Null Response? This way if the value of the tstTime is
NULL then you know that there is an issue with the timesource...

--> Todd