Re: [dss] Observations on TST

[Trevor Perrin <trevp@trevp.net>]

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.



>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?



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



>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?


Trevor