RE: [dss] Comments to draft 6 Use Case requirements

[Gray Steve <steve.gray@upu.int>]

I thought I would submit the following requirements which are specific to
the UPU's Electronic PostMark. I only received these yesterday from one of
my technical colleagues. They may be useful for the Use case requirements
document.


·	Ability to tie multiple "business transaction" lifecycle events
together under a common identifier or key. This will allow the complying
service to tie together several significant events in the non-repudiation
lifecycle.

·	Ability to "store signed content" which would be awaiting pickup by
an intended recipient. Additionally the ability to specify that the request
to retrieve this content needs to be "signed" by the intended recipient
(i.e. a "sign for pickup" facility)

·	Ability to allow other trusted service providers to "vouch for
events" in a given lifecycle. The example we most often use is the "Mail
Transport Agent" vouching for the sender that he indeed submitted a
document. Additionally the "Mail Transport Agent" can vouch to the EPM
Service that it indeed transported the particular document. This can be
accomplished by a "Vouched Event" operation. Chain of trust must be
established between "vouching" and "vouched for" parties.

·	Ability to allow a signator (acting as a sender) to request a signed
delivery and  receipt confirmation from the recipient.

·	Ability to add a timestamp to an existing signature presented by the
subscriber.

·	Ability to retrieve signature verification results, if authorized to
do so.

·	Ability to have "passed in" content checked by the service against
the content (SignedInfo) of a previously created signature over that
content. Essentially a check on the sameness of content previously signed.


Regards


Steve Gray





-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: Monday, June 02, 2003 7:37 PM
To: simeon.sheye@cryptomathic.com; dss@lists.oasis-open.org
Subject: Re: [dss] Comments to draft 6


At 09:01 AM 6/2/2003 +0000, simeon.sheye@cryptomathic.com wrote:

>Section 3.4.3 states that "The server may return the signature 
>immediately, or may return a transaction identifier, which instructs the 
>client to call back periodically and see if the signature is ready yet".
>
>I propose to move this into section 3.3 (generic request reqs). This would 
>allow the response to any request to be delivered either immediately or 
>delayed. The bullet in line 330 (section 3.5.2) should go with it.

As I recall there were 2 rationales for delayed response on the "signing" 
request/response exchange (I think we're in agreement this exchange is also 
going to be used for time-stamping):
  - where a human or other process has to approve the signature
  - linked timestamping may require it, in certain cases

I'll add those rationales to the document itself.  Is there a good 
rationale for allowing delayed response to the "verifying" request/response 
exchange?


>In section 3.7.4 ("time-stamp/time mark"), the text says "If the 
>verification was carried out for some time in the past (see 3.6.2, bullet 
>2), a time-stamp or time mark for that time should be returned as well."
>I think we should be cautious here because this makes it possible to 
>produce timestamps that dates back before the signature was actually
created.
>I propose that back-dated time-stamps are ruled out completely.

Sounds good.  I'll take that sentence out unless someone disagrees.

Trevor 


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php