RE: [dss] Compound operation Verify & Sign

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

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