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