RE: [dss] FW: Here is the TimeStamp scope question to post to the list.

[Trevor Perrin <trevp@trevp.net>]

At 04:08 PM 9/15/2003 +0200, Juan Carlos Cruellas wrote:
[...]
>2. This means that different business cases will require one or several
>of these time-stamps, but that the decission of which one(s) will usually
>have to be made by designers of the systems that will likely profile it in
>accordance, or alkternatively, for those individual with few background, some
>advices can be given by the server itself or even the recepient of the signed
>document (for instance, public agencies....). What I mean is taht I think that
>time-stamps will be used in environments where somebody will have established
>a set of rules identifying what kind of time-stamps need to be managed....

I agree with the above.  But that makes me think details of timestamping a 
signature will usually be part of the Application Profile or Implicit 
Parameters of the server, so we don't need to communicate it from client to 
server.  Or at least, we shouldn't put all these notions of different 
timestamp types in the core.

This was raised to the list before, my response -
http://lists.oasis-open.org/archives/dss/200308/msg00039.html

 >>1) If one agrees that there could exist more than one type of a timestamp,
 >>which types of timestamps is DSS intending to support ?

[....]we can separate "intending to support" into 2 questions:
   1) can the protocol be used to produce a signature with a certain type of
time-stamp?
   2) can the protocol be used to *explicitly request* a signature with a
certain type of time-stamp?

For the 1st, the answer should be yes to everything.  If a time-stamp is
just an attribute to a signature format we support, there should be no
trouble with returning a signature containing such a time-stamp.

So your question is about the second -  what type of support do we need in
the SignRequest message for the client to explicitly control timestamps on
signatures?

It's not clear to me that we need *any* explicit support for this.  Perhaps
an ApplicationProfile would say "always apply a SignatureTimeStamp", or
"always apply an AllDataObjectsTimeStamp", or whatever.  Then the client
gets no control at all.

Or maybe the ApplicationProfile would say "if the client requests a
time-stamp, then apply a SignatureTimeStamp".  Then the client would just
say "timestamp/don't timestamp", and the server would know which type to apply.

My point is: this isn't a question of "do we support these types of
time-stamps or not", it's a question of "how much control do we give the
client".


Trevor