RE: [dss] Re: TSTInfoType

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

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.