[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Compound operation Verify & Sign
Couldn't a single typed element be used, e.g. <IncludeContentTimeStamp type="dss:XAdES-X-L"> and the type used to identify both the response value and the option request? Thus one element could be defined but revised for variations without necessarily core revisions? (I'm probably missing something in the details regarding anticipated side-effects.) regards, Frederick Frederick Hirsch Nokia Mobile Phones > -----Original Message----- > From: ext Edward Shallow [mailto:ed.shallow@rogers.com] > Sent: Tuesday, November 04, 2003 10:08 AM > To: 'Trevor Perrin'; 'Nick Pope' > Cc: dss@lists.oasis-open.org > Subject: RE: [dss] Compound operation Verify & Sign > > > Yes Trevor it could be as simple as that. > > Aside from the point that the illustration below is too > general, I agree > with your stance. I suspect that the exact nature of the > request option has > to be a little clearer and express exactly what is desired of > the service, > but your point is taken. > > Examples: > > Core: > ***** > <IncludeContentTimeStamp/> > <IncludeSignatureTimeStamp/> > > Some Profile: > ************* > <IncludeTimeStampXAdES-X/> - > SigAndRefsTimeStamp as per > ETSI > <IncludeTimeStampXAdES-X-L/> - Certificate > and revocation > values as per ETSI > <IncludeTimeStampXAdES-A/> - this is the archive or > freshened timestamp over the previous X-L > <ReturnDetachedTimeStampToken/> - this is > required for requesters > who don't want the timestamp embedded in the signature > > ... > > As you can see Nick, it is not a trivial exercise to simply > state "let's > have an "Updated Signature" element in every profile. It is much more > complicated than that. Just think of CMS versus XMLDSIG and > embedded versus > detached both of which are possible in either CMS or XMLDSIG. > It does not > have to be complicated if we STAY WITHIN the domain of the > core, or just the > Content and Signature timetamps that Trevor has in the schema > already. > > The challenge with DSS is that the extensibility MUST apply > to all request > structures, response structures, results structures, and > options elements. > We have to do all or none to be consistent. If you decide to > do all for > common cross-profile elements you are already 3/4 of the way > to defining the > profile. I dare say for example that the DSS team is not > equipped to predict > all the intent and scope of each profile at this early stage. > This is the > whole reason we introduced profiles in the first place. I'm > sure our intent > was not to turn around and attempt to start defining them > when the ink is > hardly dry on the core itself. > > Ed > > > -----Original Message----- > From: Trevor Perrin [mailto:trevp@trevp.net] > Sent: November 4, 2003 3:13 AM > 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_w > > > > > or > > > > 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/leav > e_workgroup.ph > p. > > > 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 > . > > > > 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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]