RE: [dss] Re: TSTInfoType

["Dimitri Andivahis" <dimitri@surety.com>]

Trevor,
Here is the sketch of my proposal in XML.

1. Proposed definition for the TstInfoType

<xs:complexType name="TstInfoType">
    <xs:attribute name="SerialNumber" type="xs:integer"/>
    <xs:attribute name="CreationTime" type="xs:dateTime"/>
    <xs:attribute name="Policy" type="xs:anyURI" use="optional"/>
    <xs:attribute name="TSA" type="xs:anyURI" use="optional"/>
    <xs:attribute name="ErrorBound" type="xs:duration"/>
    <xs:attribute name="Ordered" type="xs:boolean" default="false"/>
</xs:complexType>

where:
  <xs:attribute name="TSA" type="xs:anyURI" use="optional"/>
  TSA [Optional]
  This attribute SHALL identify the TSA that issued the token.

is the only attribute added to the ones already defined in WD-04.
Adding the optional attribute "TSA" allows identifying
the issuer in the absence of a <ds:Signature> in the token
(see below).

2. Proposed definition for the time stamp token <Tst>

In place of the one in WD-04
  <xs:element name="Tst" type="ds:SignatureType">
that comes with the added requirement that a <TstInfo> 
element MUST be included in the <Tst> element as 
a <ds:Signature/Object> element, I propose the following:

<xs:element name="Tst">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="TstInfo" type="tst:TstInfoType" />
        <xs:element name="LinkingInfo" type=dss:AnyType minOccurs="0"/>
        <xs:element ref="ds:Signature" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
</xs:element>

In this definition, the signature within a <Tst>, if present, 
MUST include a <ds:Reference> identifying the corresponding timestamped 
document (just like the corresponding <Tst> defined in WD-04), 
and MUST include a <ds:reference URI=...> that covers at least 
the <TstInfo> element within the <Tst>.
For example, if the signature includes a <ds:reference URI=""> 
with the Enveloped Signature Transform 
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/Overview.html#sec-EnvelopedSignature
all elements in the enveloping <Tst> other than the <ds:Signature>
are also protected.

This proposed definition for the <Tst> doesn't add any burden for timestamp 
token providers who will use simple DSS signing services for timestamping.  
It also allows for providers who apply linking methods and sign everything 
in the resulting token to do so very easily.  Finally, it permits providers 
who use linking but do not add a <ds:Signature> in the tokens to conform 
to the same syntax.

Dimitri

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Thursday, October 30, 2003 2:09 PM
> 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_workgroup.php.