RE: [dss] Re: TSTInfoType

[Tim Moses <tim.moses@entrust.com>]

Nick - I think the only way of "stopping" our bright-spark is if the
"mustUnderstand" behaviour that we specify is something other than what they
require.

We have to decide (for each extension point) whether a processor that
doesn't understand the extension should or should not accept the enclosing
token.  I think this involves having some idea what the extension point may
be used for.  In the case of the calibration time, perhaps a processor
should be allowed to accept a token that contains this information, even if
it cannot understand it.  This would preclude the use of the same extension
for anything that was critical to the processing of the token.

All the best.  Tim.

-----Original Message-----
From: Nick Pope [mailto:pope@secstan.com] 
Sent: Monday, November 17, 2003 11:00 AM
To: 'OASIS DSS TC'
Subject: RE: [dss] Re: TSTInfoType


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
.