RE: [dss] Compound operation Verify & Sign

["Edward Shallow" <ed.shallow@rogers.com>]

I believe that subtle difference can also work. 

-----Original Message-----
From: Nick Pope [mailto:pope@secstan.com] 
Sent: November 3, 2003 10:34 AM
To: Edward Shallow; dss@lists.oasis-open.org
Subject: RE: [dss] Compound operation Verify & Sign

Ed,

My concern with just adding the signature as an output defined as part of
each application profile is that each profile will define its own output
structure for the "updated" (e.g. XAdES-L, time-stamped, counter-signed
.....) signature.

What I am suggesting is to have an common field in the result of verify
which all profiles will use.  Thus the client need not concern itself with
the different ways different profiles return the updated signature.

Nick

> -----Original Message-----
> From: Edward Shallow [mailto:ed.shallow@rogers.com]
> Sent: 03 November 2003 02:04
> To: 'Nick Pope'; dss@lists.oasis-open.org
> Subject: RE: [dss] Compound operation Verify & Sign
>
>
> Hi Nick,
>
>   Actually, the "Option" in this case is very focused. There is no 
> need to compare ins/outs across the Sign and Verify. The ancilliary 
> operation in each case should produce only what Outputs are required 
> above and beyond what is already in the core operation. This applies 
> to a SignatureTimeStamp as well as to a signature "refresh".
>
>   Additionally as I mentioned in my previous memo, no one is 
> considering the mess this will create for profile implementors and the 
> hand-cuffs it places on extensibility.
>
>   Please walk through the cases one-by-one and I believe you will see 
> the simplicity.
>
> Ed
>
> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: October 30, 2003 6:14 AM
> To: Edward Shallow; dss@lists.oasis-open.org
> Subject: RE: [dss] Compound operation Verify & Sign
>
> Ed,
>
> I agree with your aim for flexibility and that this could be achieved 
> by additions of options and outputs.
>
> However, I believe that because the basic semantics and structure of 
> the inputs/outputs of the verify and sign is different from the verify 
> (or sign) on its own.
>
> With the verify and sign a signature exists in the inputs, and an 
> updated signature in the outputs, and because this the signature is 
> both the primary input and the primary out I believe that it should 
> appear as part of the basic structure rather than the options.  Also, 
> I believe that it would make the procedures for handling the signature 
> clearer with a signature coming in feeding into the verify and an 
> updated signature coming out.
>
> So like Trevor I believe verify and sign (update siganture??) 
> operation should appear at the primary level as is it effects the 
> basic operation of the server, not as part of the options.  I do not 
> think that the addition of time-stamps to a signature is the same 
> thing.
>
> Nick
>
> > -----Original Message-----
> > From: Edward Shallow [mailto:ed.shallow@rogers.com]
> > Sent: 26 October 2003 18:50
> > To: 'Nick Pope'; dss@lists.oasis-open.org
> > Subject: RE: [dss] Compound operation Verify & Sign
> >
> >
> > Nick and Co,
> >
> >    The last suggested position I remember getting consensus on was 
> > that the request for the secondary or ancilliary operation should be 
> > expressed in the "Options" or "ProcessingOptions" structure as it 
> > was then called.
> >
> >    So in your example below, the principle operation is the "Verify".
> > The client requestor must express their desire through use of (for
> > example) an "AddContentTimeStamp" option or something similar.
> >
> >    This may necessitate additonal "Outputs" but the protocol is 
> > nicely able to handle that.
> >
> >    As it pertains to the EPM, we have need for several such compound 
> > operations, but we will use our profile extension to express them. I 
> > also remember discussing that additional and/or optional "outputs" 
> > and "results"
> > would be expressed by the requestor as "options".
> >
> >    I'll dig up the references if you wish.
> >
> > Ed
> >
> > -----Original Message-----
> > From: Nick Pope [mailto:pope@secstan.com]
> > Sent: October 24, 2003 4:28 AM
> > To: OASIS DSS TC
> > Subject: [dss] Compound operation Verify & Sign
> >
> > Following the discussion on the <Status> element brings to mind the 
> > discussion we had a few meetings ago on compound (or what Ed called
> > stacked) operations and particularly the ability to support a 
> > VerifyAndSign operation where a counter signature is applied based 
> > on whether the original signature is valid.
> >
> > I believe that such an operation is important in a number of use 
> > cases, for example, notarisation services.
> >
> > This was brought up at the F2F meeting and was included in the 
> > requirements document (3.9).  My recollection of the discussion on 
> > 22 Sept is that the only compound operation that was needed would be 
> > VerifyAndSign, although I see no record of it in the minutes.
> >
> > How do we envisage VerifyAndSign being supported in the DSS protocol?
> > Is there a way of combining the two request / response structures, 
> > or do we need to define a specific structure which is this combined
> operation?
> >
> > Nick
> >
> >
> >
> > To unsubscribe from this mailing list (and be removed from the 
> > roster of the OASIS TC), go to 
> > http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
> kgroup.php
> .
>
>
>
>
>
>
>
>
>