[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Comments to draft 6 Use Case requirements
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]