RE: [dss] UPU Electronic PostMark user case scenarios

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

Dear Colleagues

Sorry about not being able to reply to these questions sooner, but I am a
bit snowed under with work at the moment. I am receiving quite a number of
questions about the EPM and I also need to contact some of my postal
colleagues from time to time to answer some questions for me. 

Perhaps I can propose a telephone conference, involving my other postal
colleagues, to address most of the questions more efficiently.

How does that sound?


regards


Steve Gray

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: Friday, June 20, 2003 1:29 AM
To: Gray Steve; DSS TC
Subject: Re: [dss] UPU Electronic PostMark user case scenarios


At 06:26 PM 6/18/2003 -0700, Trevor Perrin wrote:

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

Just a thought about how we could implement EPM using the DSS operations.

With EPM, the sender calls Verify/ApplyPostmark, and the recipient calls 
Verify.

If we were to translate this into DSS terms, I think it would make sense 
for the sender to use the DSS Signing Protocol, and pass in a signature and 
request a time-marked countersignature.  The DSS service would verify the 
passed-in signature, and archive it, as a prerequisite to adding its 
time-marked countersignature as a "postmark".  The recipient would use the 
DSS Verification protocol to verify the signature.

The interesting thing here is that EPM Verify/ApplyPostmark would translate 
into DSS Sign, where the Verify part is carried out by the DSS/EPM service 
as a prerequisite to signing, but isn't explicitly requested by the sending 
client.


Trevor