Re: TSTInfoType

[Trevor Perrin <trevp@trevp.net>]

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