OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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,
>>advices can be given by the server itself or even the recepient of the
>>document (for instance, public agencies....). What I mean is taht I think
>>time-stamps will be used in environments where somebody will have
>>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 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?

>This was raised to the list before, my response -
> >>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
>   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
>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
>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

<JC>See my comment above</JC>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]