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:]
> Sent: Friday, October 24, 2003 5:26 AM
> To: Dimitri Andivahis;
> 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
