RE: [dss] Re: TSTInfoType

[kwouters@esat.kuleuven.ac.be]

Hi people,

I've been following the time-stamp issues on this list for a while, and I
have some observations:
You would like to have something like RFC3161.
*Some* of you would like to have linked time-stamps too.
This can happen trough extension or some structure that this TC defines.

So here's a suggestion: have a look at ISO/IEC 18014-1,2 and 3.
It contains structures for the RFC3161(part2) and for linked time-stamps
(part3).

all the best,

Karel Wouters.


On Mon, 17 Nov 2003, Nick Pope wrote:

> Tim,
>
> I am not sure how we can actually stop any "bright-spark" use of an
> extension, although I agree that guidance on expected use would be useful.
> Also, wherever we have used extensions we need to be explicit on what
> happens if the extension is not understood.
>
> A possible example of an extension to the TSTInfo structure could be
> information on the last time calibration.
>
> Nick
>
> > -----Original Message-----
> > From: Tim Moses [mailto:tim.moses@entrust.com]
> > Sent: 17 November 2003 15:33
> > To: 'Trevor Perrin'; 'Nick Pope'; 'OASIS DSS TC'
> > Subject: RE: [dss] Re: TSTInfoType
> >
> >
> > Colleagues - My feeling is that we shouldn't just add extension points, in
> > case some bright-spark thinks of something they could use it for.
> >  We should
> > have a clear idea of what it is allowed to be used for.  In
> > particular, if a
> > token is used in a SOAP header with the MustUnderstand attribute set TRUE,
> > then we must specify how a recipient must behave if it does not understand
> > information in the extension.
> >
> > All the best.  Tim.
> >
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
> > Sent: Saturday, November 15, 2003 2:48 PM
> > To: Nick Pope; OASIS DSS TC
> > Subject: RE: [dss] Re: TSTInfoType
> >
> >
> > At 06:00 PM 11/15/2003 +0000, Nick Pope wrote:
> >
> > >Dimitry, Trevor
> > >
> > >1) I agree to adding TSA to the TSTInfo so that it is equivalent to the
> > >RFC 3161 timestamp
> >
> > Yes, adding a "TSA" would make our TSTInfo more like an RFC 3161
> > TSTInfo.  The latest draft has a dss:NameType which could be used
> > for that.
> >
> >
> > >2) I suggest that TSTInfo has an extension field where other
> > >information can be added.
> >
> > Why does this need to be made extensible?  Just general principles?
> >
> >
> >
> > >3) Instead of trying to extend the RFC 3161 equivalent structure to
> > >support linked time-stamps, I suggest that this needs a different
> > >structure around the TSTInfo.
> > >
> > >4) I suggest that the core defines a generic structure for a time-stamp
> > >which includes a choice between:
> > >  - the currest TST structure providing equivalent to RFC 3161
> > >time-stamps
> > >  - base64 encoded RFC 3161 time-stamp
> > >  - ANY other profile specific time-stamp structure
> >
> > I like that.  I'll try to summarize the 3 proposed Time-Stamp formats
> > (Dimitri's, Tim's, Nick's):
> >
> > Dimitri
> > ----------
> > Dimitri suggests an enveloped signature, inside a <Tst> element, so that
> > <LinkingInfo> and the <ds:Signature> can exist side-by-side, or
> > one of them
> > can be omitted:
> >
> > <Tst>
> >    <TstInfo>
> >    <LinkingInfo>
> >    <ds:Signature>
> >      <SignedInfo>
> >      <SignatureValue>
> >      <KeyInfo>
> >    </ds:Signature>
> > </Tst>
> >
> >
> > Tim
> > ----------
> > The current timestamp format has a <Tst> element of type
> > ds:SignatureType.  This is an *enveloping* signature - the <TstInfo> is
> > inside it:
> >
> > <Tst>
> >    <SignedInfo>
> >    <SignatureValue>
> >    <KeyInfo>
> >    <Object>
> >      <TstInfo>
> >    </Object>
> > </Tst>
> >
> >
> > Nick
> > ----------
> > This adds an enclosing <Timestamp>, which can contain different types of
> > Timestamp Tokens, such as Tim's <Tst>, or a Base64-encoded RFC 3161
> > TimeStampToken, or some future thing that Dimitri defines:
> >
> > <Timestamp>
> >    <XMLTst>           <!-- per Tim's proposal -->
> > </Timestamp>
> >
> > <Timestamp>
> >    <RFC3161Tst>
> > </Timestamp
> >
> > <Timestamp>
> >    <LinkingTst>
> > </Timestamp
> >
> >
> > Personally, I like Nick's proposal, since it lets us keep the current
> > <Tst>, and it incorporates RFC 3161 timestamp tokens and other
> > types (such
> > as linking).
> >
> > 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_wor
> kgroup.php
> .
>
> 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
> .
>
>
>
>
>
> 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.
>