TSTInfoType

[Trevor Perrin <trevp@trevp.net>]

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.

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

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

I don't see this as a compromise at all, since you require that
the tokens carry a signature.

Dimitri