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] UPU Electronic PostMark user case scenarios


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

>Dear Colleagues
>
>As discussed at the previous two telephone conferences, please find 
>attached a document describing three user case scenarios for the 
>Electronic PostMark. The purpose of this document is for input to the DSS 
>Use Cases document, but primarily to provide additional business 
>application context to the general information already provided on the EPM.
>
>I am still hoping to complement this information with PowerPoint slides, 
>once I clarify any intellectual property concerns.

Hi Steve,

Some questions about the use cases:

Case 1
----------
The sender signs a document with his private key, and sends the signature 
to his EPM service.  The service verifies the signature, adds a time-stamp 
to it, archives the time-stamped signature, and returns it.  The recipient 
of the signed document sends the signature to his own EPM service for 
verification.  Then the recipient repeats this process in the other 
direction, so the document ends up with both their signatures.

I may not understand certain legal and procedural issues around digital 
signatures.  But why can't the sender just use a normal Time-Stamp 
Authority to time-stamp the signature?  Why use a special service that also 
verifies and archives it?  The receiver won't be in contact with the 
sender's EPM service, so will have to verify the signature on his own anyways.

I'm sure there's a reason for having the service verify/archive the 
signature, and I assume that by "post-marking", i.e. time-stamping, the 
signature, the sender's EPM service intends to convey "I've verified and 
archived this".  Is a time-stamp the best way of communicating that 
though?  Seems like a counter-signature would be more appropriate, though I 
guess a time-stamp isn't much different than a counter-signature.  I'm 
curious what some of the people who've worked on RFC 3161, XAdES, and 
similar things think.

Why does the recipient call the EPM service's Verify operation instead of 
just verifying the signature himself?  Is it just to spare the recipient 
the inconvenience of revocation-checking, path validation, and the 
like?  If so, I assume calling Verify is optional?

You mention the CheckIntegrity operation, but it's not clear why/when the 
recipient would call CheckIntegrity instead of Verify.

Case 2
----------
In terms of interaction with the EPM service, this seems just like case 1 
above, except that the document recipient doesn't sign it and return 
it.  Is that correct?

Case 3
----------
In terms of interaction with the EPM service, this seems just like case 
2?  I.e., client calls Verify with ApplyPostmark?


It would be interesting to see use cases that demonstrate other uses of the 
EPM service.  For example,
  - the Sign operation
  - the CheckIntegrity operation
  - the Encrypt and Decrypt operations
  - how the Evidence database is used to resolve disputes
  - non-repudiation and notification of receipt
  - the lifecycle and ParticipatingParty concepts


Trevor 



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