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
