Observations on TST

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

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"/>

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.

3. RFC 3161 and derivatives include optional accuracy and ordering
information.  An alternative approach is to consider these to be aspects of
policy.

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?


-----------------------------------------------------------------
Tim Moses
613.270.3183