[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Re: TSTInfoType
My recollection of the earlier discussion on alternative time-stamping systems is that the protocol should be sufficiently flexible to support alternative schemes but we would concentrate (in the core) on RFC 3161 time-stamping. Nick > -----Original Message----- > From: Trevor Perrin [mailto:trevp@trevp.net] > Sent: 30 October 2003 19:09 > To: dss@lists.oasis-open.org > Subject: [dss] Re: TSTInfoType > > > At 10:17 AM 10/30/2003 -0800, Trevor Perrin wrote: > > >Dimitri responded to an earlier thread on this, but I'm not sure his > >message went through to the list, so I'm forwarding it: > > > > > >Trevor, > > > > > -----Original Message----- > > > From: Trevor Perrin [mailto:trevp@trevp.net] > > > Sent: Friday, October 24, 2003 5:26 AM > > > To: Dimitri Andivahis; dss@lists.oasis-open.org > > > Subject: RE: [dss] TSTInfoType > > > > > > > > > At 07:03 PM 10/23/2003 -0400, Dimitri Andivahis wrote: > > > > > > >Trevor, > > > > > > > >As far as the <TstInfo>, I think the extra "name" > > > >attribute is all that's needed so we can use the > > > >same <TstInfo> definition for tokens that carry > > > >no ds:Signature/KeyInfo/KeyName field. > > > > > > If the <TstInfo> was re-used inside such a token, though, this > > > token could > > > probably carry the name attribute; so the name attribute might not be > > > needed in the <TstInfo>. And if we did put the name > attribute inside the > > > <TstInfo>, the attribute would be redundant when the <TstInfo> is used > > > inside a ds:Signature type of token. > > > > > > > > > >The linking information should be derived from what is currently > >described in <TstInfo> and from the issuer name. I proposed > >that an optional name attribute be defined within <TstInfo> > >so that a linking method can pick up everything it protects > >from one XML element only, not from a laundry list of elements > >as you suggest. See: > > http://lists.oasis-open.org/archives/dss/200310/msg00075.html > >for the issue of redundancy. > > I see your point. I'd just like to look at the broader issue of how > linking schemes fit with our time-stamps, before committing to this. > > > > > > >The current definition of <Tst> is not open to > > > >extensions when the token is not signed. I would > > > >argue for a token definition where the token > > > >includes the <TstInfo>, possibly the <LinkingInfo> or > > > >other elements to be determined in the future, > > > >and possibly (minOccurs="0") an enveloped <ds:Signature> > > > >over the token. > > > > > > That makes sense. The wd-03 <Tst> format has the nice > feature, though, > > > that since it's of <ds:SignatureType> it's easy to handle > with XML-DSIG > > > software. > > > > > > >The format defined in wd-03 is useful for handling the <ds:Signature> > >part of the token only. My proposal is more neutral in terms of how > >tokens are constructed (with or without linking Info, with or without > >signatures). > > Yes. But at our meetings, people have primarily wanted something similar > to an RFC 3161 signed token, perhaps with some "extensibility" to linking > schemes in the future. That's reflected in the requirements doc. > > So I'm just not sure how far we want to bend to accomodate linking > schemes. We have a token proposal that's clean and simple, and which can > have linking data added to it. > > It always carries a signature, but is that so bad? I think it's good, > because these tokens can always be verified by implementations that don't > support linking data. But implementation that do can reap the > benefits of > the linking data. > > Anyways, if you want to sketch out a different proposal so we could place > them side-by-side and consider the costs of doing things a more neutral > way, that might be helpful. > > > Trevor > > > To unsubscribe from this mailing list (and be removed from the > roster of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor kgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]