RE: [dss] Observations on TST

["Nick Pope" <pope@secstan.com>]

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 14 August 2003 18:41
> To: Dimitri Andivahis; 'DSS'
> Subject: RE: [dss] Observations on TST
>
>
> At 12:42 PM 8/14/2003 -0400, Dimitri Andivahis wrote:
> >[...]
> > > >
> > > > >3. RFC 3161 and derivatives include optional accuracy and ordering
> > > > >information.  An alternative approach is to consider these to be
> > > > aspects of
> > > > >policy.
> > > >
> > > > Fine by me.
> > > Accuracy: I prefer to keep the optional field so that this
> can be obtained
> > > without having to know the policy.  Similarly for ordering.
> > >
> >
> >I agree with Nick's proposal.
>
> One thing that worries me about the Accuracy field, as in RFC
> 3161 and the
> Entrust proposal, is that the client has to add and subtract the Accuracy
> field with the timestamp time to determine the upper and lower bounds.
>
> Isn't this non-trivial?  The client might have to know how many
> days are in
> each month, leap-years, leap-seconds, that sort of thing.
>
> Would it be easier for the server to explicitly return an upper and lower
> bound, instead of an Accuracy?
>

I am not expecting that the upper and lower bounds is the main interest.  I
see accuracy as a quality indicator.  Changing to upper and lower bounds
make it much more difficult to decide whether the time-stamp is accurate
enough for my purposes.

>
> > > >
> > > >
> > > >
> > > > >4. RFC 3161 and derivatives include a nonce in the TST.  The
> > > rationale is
> > > > >that requestors who communicate with the authority over an
> > > > untrusted channel
> > > > >must correlate requests and responses.  This correlation could
> > > > be provided
> > > > >in the request/response protocol.  But, if that layer uses
> > > signatures for
> > > > >integrity (e.g. WS-Security), then two signatures result - an
> > > > inefficiency.
> > > > >Is this a common use-case?
> > > >
> > > > That seems like a better layering, even if less efficient.  The
> > > > TimeStampResponse might have other fields in it besides the
> > > > TimeStampToken,
> > > > like the StatusInfo, which you would like to be
> > > > integrity-protected.  Also,
> > > > we've included a RequestID element in the SignRequest for this same
> > > > purpose, so why duplicate that in the TST?
> > > >
> > >
> > > I would like to keep the nonce in the time-stamp token so
> that it can be
> > > assured that each token is unique, not just for replay but for later
> > > reference to the token.
> > >
> >
> >I agree with Nick's proposal.
>
> Doesn't the serialNumber (in both RFC 3161 and Entrust's proposal) take
> care of this?  If we have the serial number, do we need a nonce?
>

Good point