Date: Thu, 10 Jul 2003 12:44:25 -0400 From: Edward Shallow <ed.s...@rogers.com>

Trevor, (as usual please post)

We actually moved away from stacked operations (i.e. VerifyAndSign,VerifyAndCounterSign, etc ...) in favor of focusing on the prime objective of the service call which was then accompanied by additonal directives or options. These options (all manifesting themselves as WSDL booleans or structures) can be crypto primitives themselves, as is the case with ApplyPostMark and VerifyCertificate, or they can simply be directives to return additional information such as ReturnX509Info and ReturnVerificationInfo, or even directives to include selected attributes.

On a related note, we contend that the Verify and TimeStamp operations are legitimate operations on their own. Trevor, you said in an earlier exchange, that a subscriber may use a separate Validation Authority and TimeStamp Authority. The TSP protocol carries a whole bunch of stuff that is truly unique to timestamping, like the nonce, a separate TSA policy, clock accuracy, the very specific and mandated return of the timestamp token and the timestamp information strucure (i.e. TSTInfo). These are all very different from the more conventional Sign request / response structures. A caller is not even allowed to specify a signing (timestamping) key, that is the TSA's responsibility. You will have to create all sorts of pre-conditions on your Sign operation for the TimeStamp requests. Sure you can simply abstract out the details claiming it is fundamentally a Signature creation exercise, but I believe you loose a lot of context and you confuse by overloading the Sign with a radically different profile (See Vincent Girier's ISSE XML TimeStamping submission to this group).

I contend that a Verify operation with an ApplyTimeStamp option directive would be better. Furthermore, I believe an elementary TimeStamp deserves its own primary verb. TimeStamping has been around a long time and is well understood and deployed under its current definition. Don't lose that momentum.

In this multi-operation-per-request scenario (as you call it) you have to keep and return the results of each operation separately. The caller is definitely interested in the Verify results containing both signature and certificate verification info as well as the timstamp results containing the timestamp time, the timestamp token (perhaps inserted back into the incoming signature as an unsigned attribute, perhaps separate).

Another scenario you have not addressed is one where the incoming signature already has a timestamp attached to it. Perhaps the subscriber just wanted an origin timestamp (e.g. a filed my tax return on time) and requested a TimeStamp or a Verify with ApplyTimeStamp. Then the tax department wants this incoming signature (tax filing) verified. The tax department calls the DSS with a destination Verify ApplyTimeStamp. Does the DSS obliterated the origin timestamp embodied in the signature ? I doubt it. Does it verify both the signature and the timestamp contained therein ? Or does it verify both signature and origin timestamp AND return a destination timestamp ?

Effects on the operation and its options ? Large. Please throw this scenario into the demand side of the equation, it will happen in real life.