RE: [dss] Observations on TST

["Dimitri Andivahis" <dimitri@surety.com>]

Nick, Trevor, Tim,

> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: Thursday, August 14, 2003 9:24 AM
> To: Trevor Perrin; Tim Moses; 'DSS'
> Subject: RE: [dss] Observations on TST
> 
> 
> Trevor, Tim,
> 
> Adding my thoughts
> 
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
> > Sent: 13 August 2003 23:30
> > To: Tim Moses; 'DSS'
> > Subject: Re: [dss] Observations on TST
> >
> >
> > At 04:27 PM 8/13/2003 -0400, Tim Moses wrote:
> >
> > >Colleagues - In reviewing the various definitions for a
> > timestamp token, I
> > >make the following observations.  We should schedule a
> > discussion of these
> > >issues and come to a decision on their resolution.  All the best.  Tim.
> > >
> > >1. The Entrust submission defines a <dss:Digest> element that is
> > virtually
> > >identical to the <ds:Reference> element definition.  Perhaps, we
> > should just
> > >import the XML DSig definition.  I.e. ...
> > >
> > ><xs:element ref="ds:Reference"/>
> >
> > We could also have a timestamp cover *multiple* ds:References, like an
> > XML-DSIG does.
> >
> I agree with Trevor.  If a signature can be applied to multiple 
> objects why
> not a time-stamp.
> 

I too agree with Trevor's proposal.  Multiple ds:References could refer
to the same data (using different digest methods) or to different data.

> >
> >
> > >2. The Entrust submission does not include the name of the 
> issuer in the
> > >timestamp token.  The rationale is that the token must be 
> signed and the
> > >name of the issuer will be found in the subject field of the 
> certificate
> > >that verifies the signature.  Perhaps, we should (at least) 
> allow for the
> > >optional inclusion of an issuer field, so that a system that uses a
> > >mechanism other than X.509 certificates for integrity can have a
> > conformant
> > >TST.
> >
> > Can we assume the signature's ds:KeyInfo identifies the TSA, whether
> > through a cert or something else?
> >
> >
> Again, lets keep the general structure like a signature
> 

I disagree with Nick's proposal, I propose that we follow Tim's 
suggestion and include an optional issuer field in the time stamp info 
for the reasons he stated.

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

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

> Nick
> 
> 
> 
> You may leave a Technical Committee at any time by visiting 
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php


Dimitri Andivahis