RE: [dss] Timestamping

[Trevor Perrin <trevp@trevp.net>]

Hi Dimitri,

To explain my point on the call -

If a timestamp needs to be handed to a TSA of a particular type to be 
verified, then the timestamp might as well be opaque to any client - a 
client requests it be created, and then some other client requests it be 
verified, but the client doesn't care about the contents.

I think the value of spec'ing the internals of a linked timestamp format is 
only if we want independently implemented TSAs and timestamp "verifiers" 
(which may or may not be TSAs themselves) to interoperate, i.e. if we want 
a timestamp produced by a TSA to be verifiable by independently implemented 
verifying services.

But achieving that seems complicated.  The TSA producing a timestamp has 
lots of options, in terms of different aggregating, accumulating, linking, 
and publishing schemes.  Either we'd need to only support a specific 
approach to each of these, or design a data format and verifying algorithm 
(and perhaps other supporting protocols/data formats, for publishing 
derived values and retrieving them) so general it would work no matter how 
the timestamp issuer does things.

Probably either way is doable, but given that we can do a simple, signed 
timestamp that's "good enough" for most people, and given that linking 
schemes are IPR-encumbered, I think we should design a format and protocol 
general/extensible enough to support linking schemes in the future, but not 
tackle them right away.

But we should figure out what requirements we need to put in, to support 
extensibility to linking schemes.  For example, you mentioned that 
timestamp production might be a 2-phase process, where you get part of the 
signature right away, and then come back after a round ends to get the 
rest.  What other specific requirements would we need to add to support 
linked schemes?

Trevor