Timestamping

[Trevor Perrin <trevp@trevp.net>]

The requirements subcommittee is considering what the requirements should 
be for a timestamp format and protocol.  We'd like some input from the 
group, since this hasn't had much discussion yet.

Currently, the notions of time-marked signatures and time-stamped 
signatures have been defined:

A time-marked signature is just a signature on some content with a signed 
attribute (created by the signer) containing the signing time.

A time-stamped signature contains, as an unsigned attribute, a timestamp 
"token", which somehow binds the time and a hash of the time-stamped 
signature's signatureValue, and is created and signed by a 3rd party TSA 
(Time Stamp Authority).

More generally, a timestamp token may be used to timestamp other things 
than a signatureValue.

Now, whatever format the timestamp token takes, a timestamp protocol just 
requires the client send a hash and receive back a token.  This shouldn't 
be any different from the DSS protocol used in the "client-side hashing" 
and "receiving a detached signature" case.  Thus, time-stamping should just 
be a use-case of the DSS protocol, not a separate protocol.

As for an XML timestamp token format, there's two approaches:
A) Define a time-stamp token as just a time-marked signature produced by a 
3rd-party that's trusted as a TSA.
B) Define a time-stamp token as a signature on some new <TSTInfo> structure 
containing a hash of the to-be-timestamped data and the time.

In (A), the TSA produces a normal signature using the hash of the 
to-be-timestamped data, with time as a signed attribute.  In (B), the TSA 
combines the hash of the to-be-timestamped data with the time into a new 
structure, and produces a normal signature on that.  (B) is the approach 
used in RFC 3161, which is PKIX's timestamping protocol, and is used to 
timestamp CMS signatures.

The benefit of (A) is that timestamps aren't handled differently from any 
other signature type, they're just a particular "semantics" instead of 
"syntax".  The argument against this, is that timestamps *are* different 
from other signatures:  Normally signatures testify that the contents are 
associated with the signer as an originating entity, not that the contents 
are associated with a time.  So timestamps should have a different syntax 
to ensure that they're processed correctly, and that a Relying Party 
understands that the time is the important thing, and doesn't mistakenly 
ignore a signing-time signed attribute and think the TSA originated the 
to-be-signed data.

One way of framing the question: what are the semantics of a raw, DSIG 
signature?  If a DSIG signature is just a statement of the form "someone 
says something about some data", where
  - the speaker ("someone") is identified with a <KeyInfo>
  - the object ("some data") is identified with a <SignedInfo>
  - the predicate (what is being said about the object) is identified by 
the <KeyInfo>'s properties/policy identifiers and signed attributes

Then asserting that the data existed at a certain time is just another 
predicate that can be asserted about <SignedInfo>, along with asserting 
that you originated it, or asserting that you agree to its contents, or 
asserting that it really came from some Identified Requestor.

But if a DSIG signature also carries the semantics that the signer 
originated the data, then it would be misleading for a TSA to produce a 
signature on the to-be-timestamped hash while relegating the signing time 
to a signed attribute (but then wouldn't any use case where the server 
didn't originate the data, but just signed a hash, be misleading?).

But that may be unfair (I'm biased towards A).  What do other people prefer?

Trevor