RE: [dss] Compound operation Verify & Sign

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

This brings to mind an alternative approach which might be more appropriate
than a verify and sign:

The <Signature> structure could be included as an optional element in the
results structure of Verify.  This could contain an updated copy of the
signature which has been verified with the addition of CRL etc as identified
below, archive time-stamps or any counter signatures.  The required function
can be controlled through the necessary <Options>.

I recognise that a new VerifyAndSign operation would be misleading if the
signature is just updated with the CRL and certificates and an additional
signature is not necessarily applied.

As before I also prefer this approach to just placing <signature> as I see
it as being a primary part of the core protocol which may be used by several
of the profiles.

Does this suite you as a way forward Ed?

Nick

> -----Original Message-----
> From: Karel Wouters [mailto:Karel.Wouters@esat.kuleuven.ac.be]
> Sent: 30 October 2003 13:14
> To: Nick Pope
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] Compound operation Verify & Sign
>
>
> a little addition to the discussion:
>
> I think the 'verify and sign' operation is the equivalent to the 'initial
> verification', as discussed in CWA 14171. This operation adds data
> to the signature that can be used in a future verification (time-stamp,
> CRL information, etc). An example could be a basic XAdES signature that
> is extended to a XAdES-X-L signature by the server.
> This information is used later on in so-called 'usual verifications'.
>
> I won't make a judgment on whether or not this should appear on the
> primary level. I only want to remark that the two kinds of verification
> are very different.
>
> all the best,
>
> Karel.
>
>
>
>
> On Thu, 30 Oct 2003, Nick Pope wrote:
>
> > 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
> > .
> >
> >
> >
> >
> >
> >
> >
> > 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.
>