RE: [dss] Re: TSTInfoType

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

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_workgroup.php
.