RE: [dss] TSTInfoType

[Trevor Perrin <trevp@trevp.net>]

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

Is it a reasonable compromise to say that our XML timestamps MUST always be 
signed, but they could have linking information as well?  Then our 
timestamps are always backwards-compatible.  A non-linking implementation 
can *always* verify a time-stamp, but a linking implementation can take 
advantage of the higher degree of assurance that linking offers.

Is this a good way forward?

Trevor



>Dimitri
>
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
> > Sent: Wednesday, October 22, 2003 5:32 AM
> > To: Dimitri Andivahis; dss@lists.oasis-open.org
> > Subject: Re: [dss] TSTInfoType
> >
> >
> > At 01:50 PM 10/20/2003 -0400, Dimitri Andivahis wrote:
> >
> > >I propose adding the following optional attribute to
> > >the TstInfoType complex type:
> > >
> > >   <xs:attribute name="TSA" type="xs:anyURI" use="optional"/>
> > >
> > >   TSA [Optional]
> > >   This attribute SHALL identify the TSA that issued the token.
> > >
> > >This will facilitate future extensions of the protocols
> > >to TSAs using mechanisms other than X.509 certificates.
> >
> >
> > Tim's intent, I think, was for the name of the TSA to be carried in the
> > ds:Signature/KeyInfo/KeyName field.
> >
> > To help consider your proposal, can we look into how extending the
> > time-stamp format would work?  How do you see the current <Tst> and
> > <TstInfo> being extended?  Could linking information be added as
> > additional
> > "signed attributes" within a <Tst>?  Or would you just re-use the
> > <TstInfo>
> > inside a different wrapper?
> >
> > 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_workgroup.php.