RE: [dss] Compound operation Verify & Sign

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

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
.