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

["Nick Pope" <pope@secstan.com>]

-----Original Message-----
From: Edward Shallow [mailto:ed.shallow@rogers.com]
Sent: 16 September 2003 19:35
To: 'Juan Carlos Cruellas'
Cc: 'Nick Pope'; 'Trevor Perrin'
Subject: RE: [dss] FW: Here is the TimeStamp scope question to post to
the list.


Yes JC, I totally agree with your observation below. See my other comments
on the same subject.

Ed


-----Original Message-----
From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.es]
Sent: September 16, 2003 11:31 AM
To: OASIS DSS TC
Cc: Ed Shallow

At 13:23 15/09/2003 -0700, Trevor Perrin wrote:
>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.
>
<JC>
This would be true if always the environment from the requester would
exactly correspond to one of the application profiles already defined in the
server.
Think that we do not have control on  the number of potential clients of
this server. And perhaps some of them would request a combination of
time-stamps and other things that none of the application profiles of the
server have.... is going the server to build up an applkication profile for
that specific client? if so, how many clients would like to be invoiced by
the seting up of this application profile? would not be easier to leave
these options open so that those clients whose needs are not satisfied by
none of the profiles already defined in the server can request what they
require?
</JC>

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

<JC>See my comment above</JC>
>
>Trevor
>