[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Observations on TST
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]