RE: [dss] Re: TSTInfoType

[Trevor Perrin <trevp@trevp.net>]

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