RE: [dss] Compound operation Verify & Sign

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

Ed,

I agree that we cannot finalise the core until we have progressed some way
with the profiles sufficient to identify needs to augment the core.

Nick

> -----Original Message-----
> From: Edward Shallow [mailto:ed.shallow@rogers.com]
> Sent: 04 November 2003 14:19
> To: 'Nick Pope'; dss@lists.oasis-open.org
> Subject: RE: [dss] Compound operation Verify & Sign
>
>
> PostScript:
>
> The other issue with pursuing a common field across all profiles, is the
> related question you asked me to post to the list during yesterday's
> conference call. That is should the core schema include elements from
> profiles some of which have yet to be defined. I'll context and post that
> series of questions in a separate post, but it is safe to say that your
> suggestion should be parked until we get a resolution on core
> versus profile
> handling.
>
> On another note, we had previously suggested that procedureal
> mechanisms for
> accepting and vetting profiles before they are published could be
> instituted. I believe trying to provide consistency in advance of full
> profile definition and submission will be fruitless. There will
> be more than
> one common element that is outside of core but potentially common across a
> series of profiles.
>
> Alignment and consistency verification can more easily be done at profile
> submission time. If there is enough overlap with core and/or with
> all other
> profiles, we have occasion and opportunity to augment the core, else it
> stays in the profile and is made consistent with the other profiles.
>
> I'll pick up this discussion in the other thread.
>
> Ed
>
> -----Original Message-----
> From: Edward Shallow [mailto:ed.shallow@rogers.com]
> Sent: November 3, 2003 8:43 PM
> To: 'Nick Pope'; dss@lists.oasis-open.org
> Subject: RE: [dss] Compound operation Verify & Sign
>
> I believe that subtle difference can also work.
>
> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: November 3, 2003 10:34 AM
> To: Edward Shallow; dss@lists.oasis-open.org
> Subject: RE: [dss] Compound operation Verify & Sign
>
> Ed,
>
> My concern with just adding the signature as an output defined as part of
> each application profile is that each profile will define its own output
> structure for the "updated" (e.g. XAdES-L, time-stamped, counter-signed
> .....) signature.
>
> What I am suggesting is to have an common field in the result of verify
> which all profiles will use.  Thus the client need not concern itself with
> the different ways different profiles return the updated signature.
>
> Nick
>
> > -----Original Message-----
> > From: Edward Shallow [mailto:ed.shallow@rogers.com]
> > Sent: 03 November 2003 02:04
> > To: 'Nick Pope'; dss@lists.oasis-open.org
> > Subject: RE: [dss] Compound operation Verify & Sign
> >
> >
> > Hi Nick,
> >
> >   Actually, the "Option" in this case is very focused. There is no
> > need to compare ins/outs across the Sign and Verify. The ancilliary
> > operation in each case should produce only what Outputs are required
> > above and beyond what is already in the core operation. This applies
> > to a SignatureTimeStamp as well as to a signature "refresh".
> >
> >   Additionally as I mentioned in my previous memo, no one is
> > considering the mess this will create for profile implementors and the
> > hand-cuffs it places on extensibility.
> >
> >   Please walk through the cases one-by-one and I believe you will see
> > the simplicity.
> >
> > Ed
> >
> > -----Original Message-----
> > From: Nick Pope [mailto:pope@secstan.com]
> > Sent: October 30, 2003 6:14 AM
> > To: Edward Shallow; dss@lists.oasis-open.org
> > Subject: RE: [dss] Compound operation Verify & Sign
> >
> > 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
.