RE: [dss] Observations on TST

[Trevor Perrin <trevp@trevp.net>]

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?


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

Trevor