[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]