RE: [dss] Compound operation Verify & Sign

["Nick Pope" <pope@secstan.com>]

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
.