re: [dss] Compound operation Verify & Sign

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

Trevor,

Something of this kind would be OK.

Perhaps the options would need to be more specificly targetted at a
particular way in which the signature is updated, but I suggest that a
common syntax can be used for the result.  An  output <Updated Signature>
meets what I was looking for.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 04 November 2003 08:13
> To: Edward Shallow; 'Nick Pope'
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] Compound operation Verify & Sign
>
>
>
> Ed, Nick,
>
> Just to check if an agreement's been reached: you don't want a
> VerifyAndSign protocol; but you do want an Option on the Verify
> protocol to
> return a "freshened" signature?
>
> Could this be as simple as:
>
> <Options>
>     ......
>    <RequestUpdatedSignature/>
> </Options>
>
> <Outputs>
>    <UpdatedSignature>
>      ......
>    </UpdatedSignature>
> </Outputs>
>
> ?
>
> Trevor
>
>
>
> At 09:21 PM 11/2/2003 -0500, Edward Shallow wrote:
>
> >Nick,
> >
> >   What you described in the 2nd paragraph below is exactly what
> we had been
> >discussing all along, i.e. "Options" driving ancilliary
> operations driving
> >additional "Outputs" or "Results". I have not problem with this
> other than I
> >doubt we can call it an alternative.
> >
> >   Example: VerifyAndAddArchiveTimeStamp or Freshen etc...
> simply performs a
> >conventional Verify followed by an appropriately structured TimeStamp and
> >returns it as an additional base64 or XML signature which MUST
> be reflected
> >as an optional response element in the Verify which can be
> re-used for any
> >"Option" forcing return of a detached TimeStamp. If the TimeStamp is
> >referenced in the XMLDSIG Object structure as does ETSI, then the extra
> >response element may not be required. This example is academic
> as I suspect
> >ArchiveTimeStamp in the ETSI definition is non-core anyway.
> >
> >   Additionally, results of the ancilliary operation must be clearly
> >understandable as coming from the ancilliary operation and the not the
> >primary operation.
> >
> >    As we get into this, any attempt to capture all compund operation as
> >native compound operations (e.g. VerifyAndFreshenTimeStamp sic !!!) will
> >quickly degrade into permutations and combinations which will prove too
> >numerous .
> >
> >Ed
> >
> >-----Original Message-----
> >From: Nick Pope [mailto:pope@secstan.com]
> >Sent: October 31, 2003 5:49 AM
> >To: Ed Shallow
> >Cc: dss@lists.oasis-open.org
> >Subject: RE: [dss] Compound operation Verify & Sign
> >
> >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.
> > >
> >
> >
> >
> >
> >
> >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_wo
> rkgroup.php.
>
>
>