RE: [dss] Re: TSTInfoType

["Nick Pope" <pope@secstan.com>]

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
.