RE: [dss] Compound operation Verify & Sign

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

This addresses my main concern that we have a way of supporting the compound
operations.

On the details I don't think that a generic request option "request updated
signature" helps.  It is better to have a specific option relating to the
partical action required.

However, I still believe that a generic Output element for carrying the
signature response rather than a particular syntax for each form of
signature.  But I can accept following the majority view with this.

Nick

> -----Original Message-----
> From: Edward Shallow [mailto:ed.shallow@rogers.com]
> Sent: 05 November 2003 15:51
> To: 'Trevor Perrin'
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] Compound operation Verify & Sign
>
>
>
>
> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: November 5, 2003 4:40 AM
> To: Edward Shallow
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] Compound operation Verify & Sign
>
> At 11:09 PM 11/4/2003 -0500, Edward Shallow wrote:
>
> >A PostScript clarification:
> >
> >1) If it is an XAdES-T or XAdES-X that is required and the first Verify
> >has not as yet been performed, then it is an include timestamp option
> >on a Verify. In fact it could be either the first Verify or a later
> >timestamp request where we decide it is good practive to re-verify.
> >
> >2) If it is an XAdES-C that is required it is very likely that the
> >Verify has not yet taken place, although it is possile that it has and
> >there already exists a Content or Signature timestamp in the incoming
> signature.
> >However to avoid adding another protocol operation to DSS (i.e. an
> >UpgradeSignature) we could put this on the back of the Verify and
> >assume that re-verification (i.e. if indeed one has taken place) is
> good-practice.
> >Besides, most crypto toolkits only give you back all this XAdES-C
> >ValidationData when one performs a Verify anyway. That would be my vote.
> >
> >5) If it is an XAdES-A that is required, I wouldn't attempt the Verify,
> >it is not the intention of this signature type. This falls neatly into
> >the Sign with Option.
> >
> >4) If it is an XAdES-X that is required, it is more subtle, but I
> >believe the same premises as in 2) above hold. In fact, XAdES-X is just
> >a better and tighter implementation of XAdES-C.
> >
> >5) XAdES-X-L is troublesome. I'm open to suggestions. But my gut
> >reaction is to leave it to the extended profiles.
> >
> >
> >Ed's Assertion:
> >
> >All but XAdES-T could be left to the extended profiles.
>
> So if I'm hearing right, you're saying all we need in the core is the
> Option, on Verify, to add a time-stamp over the signature?  Perhaps we can
> just re-use the <SignatureTimestamp> Option for this?, and have the server
> return something like:
>
> <dss:TimestampedSignature>
>    <dss:Signature>...</dss:Signature>
> </dss:TimestampedSignature>
>
> <ed>
> Yes, you are right, we would have to add some element to the
> Verify response
> which presently has no signature return element. We could add the same
> option and element to the Sign as well ONLY IF everyone agrees
> that forcing
> a (re)Verify when adding a timestamp is not appropriate. If
> everyone has no
> problem with the (re)verification approach, then yes would you
> suggest looks
> good.
> </ed>
>
> Or maybe we could use a more generic name like
> <RequestUpdatedSignature>, on
> the theory that different service profiles / service policies can
> interpret
> this to mean whatever they want (time-stamping, add validation data,
> whatever).  So it's a single syntax that would take on different meanings
> depending on the profile/policy.
>
> <ed>
> Personally, I would rather see more focused element usage without too much
> overloading. Specific profiles will invariably add more to suit
> their needs
> as they implement the more advanced timestamps and extended options. The
> response elements will vary, type attributes will be required,
> etc, etc  ...
> They (I) will basterdize this generic element to the point where it is
> useless. Again, why start if you are not going to finish. Leave
> these unique
> and additional response element requirements to the extended
> profiles. What
> you have suggested above in your 1st paragraph is whole and consistent.
> </ed>
>
>
> Is this in the right direction, at least?  If not, what concrete
> options/outputs do you think should we add to the core?
>
> <ed> Absolutely. None. </ed>
>
> Trevor
>
>
>
> 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.