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 01:25 PM 6/20/2003 +0200, Juan Carlos Cruellas wrote:

>Trevor,
>see comments below:
>At 16:28 19/06/2003 -0700, Trevor Perrin wrote:
> >At 06:26 PM 6/18/2003 -0700, Trevor Perrin wrote:
> >
> >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".
>
><JCC>Perhaps I missunderstands what you are saying, but to
>me it seems that by doing this we would allow to a client to send
>a request for generating a time-marked   countersignature (ie a signature
>of a signature value) BUT the service would have to perform first a
>verification
>of the incoming data? I think that we should add to the requirements on the
>requests some additional piece of data for complementing the initial request,
>otherwise the server will have to look at the semantics of what arrives to
>it, and this
>seems too complicated to me...</JCC>

You mean add, to the Request message, an indication that the input 
signature should be verified before it is counter-signed?

I'm not sure we need that - we've already talked about how different types 
of DSS services might do different things to the signature request before 
signing it (such as archiving it, passing it to a human for review, 
validating it in various ways, etc..).  I don't think it's the client's job 
to request these operations - the service will know what it needs to do, 
based on whether it's an EPM service, or an eNotary service, or whatever.

Maybe we can mention in "3.4.4 Signature Policy" that whether the server 
archives, and how it validates, the request, might be other aspects 
controlled by the Signature Policy the client selects.  Then the client 
could have some control over them, but we don't need to explicitly add 
elements for this.  I'd just like to avoid complicating the client/server 
interface with too many options.

Trevor 



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