RE: [dss] Compound operation Verify & Sign

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

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