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

[Trevor Perrin <trevp@trevp.net>]

At 05:57 PM 6/17/2003 +0200, Gray Steve wrote:


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

Hi Steve,

you brought these requirements up a while ago.  There's some interesting 
things here we should try to include in the DSS requirements, but I'm still 
trying to understand some of them.  I'll bring this up on the concall, but 
mostly some examples would be helpful.  And some of these may apply to EPM, 
but not DSS.



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

Could you give an example?


>·       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)

The service can function as a document transport mechanism?  I assume this 
wouldn't apply to DSS, but I'm still a little curious when/why would this 
be useful?  What EPM operations are called to implement this on the Sender 
and Receiver sides?


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

How does this work when Sender and Recipient are using different EPM services?


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

Why not use a normal Time-stamp Protocol (like RFC 3161)?


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

When would this be useful?  Why would Alice want to retrieve Bob's 
signature verification results?


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

When this would be useful?

Trevor