RE: [dss] Observations on TST

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

Trevor, Tim,

Adding my thoughts

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 13 August 2003 23:30
> To: Tim Moses; 'DSS'
> Subject: Re: [dss] Observations on TST
>
>
> At 04:27 PM 8/13/2003 -0400, Tim Moses wrote:
>
> >Colleagues - In reviewing the various definitions for a
> timestamp token, I
> >make the following observations.  We should schedule a
> discussion of these
> >issues and come to a decision on their resolution.  All the best.  Tim.
> >
> >1. The Entrust submission defines a <dss:Digest> element that is
> virtually
> >identical to the <ds:Reference> element definition.  Perhaps, we
> should just
> >import the XML DSig definition.  I.e. ...
> >
> ><xs:element ref="ds:Reference"/>
>
> We could also have a timestamp cover *multiple* ds:References, like an
> XML-DSIG does.
>
I agree with Trevor.  If a signature can be applied to multiple objects why
not a time-stamp.

>
>
> >2. The Entrust submission does not include the name of the issuer in the
> >timestamp token.  The rationale is that the token must be signed and the
> >name of the issuer will be found in the subject field of the certificate
> >that verifies the signature.  Perhaps, we should (at least) allow for the
> >optional inclusion of an issuer field, so that a system that uses a
> >mechanism other than X.509 certificates for integrity can have a
> conformant
> >TST.
>
> Can we assume the signature's ds:KeyInfo identifies the TSA, whether
> through a cert or something else?
>
>
Again, lets keep the general structure like a signature

>
> >3. RFC 3161 and derivatives include optional accuracy and ordering
> >information.  An alternative approach is to consider these to be
> aspects of
> >policy.
>
> Fine by me.
Accuracy: I prefer to keep the optional field so that this can be obtained
without having to know the policy.  Similarly for ordering.

>
>
>
> >4. RFC 3161 and derivatives include a nonce in the TST.  The rationale is
> >that requestors who communicate with the authority over an
> untrusted channel
> >must correlate requests and responses.  This correlation could
> be provided
> >in the request/response protocol.  But, if that layer uses signatures for
> >integrity (e.g. WS-Security), then two signatures result - an
> inefficiency.
> >Is this a common use-case?
>
> That seems like a better layering, even if less efficient.  The
> TimeStampResponse might have other fields in it besides the
> TimeStampToken,
> like the StatusInfo, which you would like to be
> integrity-protected.  Also,
> we've included a RequestID element in the SignRequest for this same
> purpose, so why duplicate that in the TST?
>

I would like to keep the nonce in the time-stamp token so that it can be
assured that each token is unique, not just for replay but for later
reference to the token.

Nick