RE: [dss] Compound operation Verify & Sign

[Trevor Perrin <trevp@trevp.net>]

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>

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.

Is this in the right direction, at least?  If not, what concrete 
options/outputs do you think should we add to the core?

Trevor