RE: [dss] Compound operation Verify & Sign

[Trevor Perrin <trevp@trevp.net>]

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_workgroup.php.