|Trevor Perrin||Jul 9, 2003 9:59 am|
|Trevor Perrin||Jul 9, 2003 10:38 am|
|Trevor Perrin||Jul 9, 2003 7:55 pm|
|Trevor Perrin||Jul 9, 2003 9:41 pm|
|Gray Steve||Jul 10, 2003 12:17 am|
|Nick Pope||Jul 10, 2003 1:49 am|
|Trevor Perrin||Jul 10, 2003 2:03 am|
|Trevor Perrin||Jul 10, 2003 2:11 am|
|Nick Pope||Jul 10, 2003 2:33 am|
|Trevor Perrin||Jul 10, 2003 9:49 am|
|Trevor Perrin||Jul 10, 2003 12:07 pm|
|Trevor Perrin||Jul 10, 2003 2:57 pm|
|Nick Pope||Jul 11, 2003 1:46 am|
|Gray Steve||Jul 11, 2003 8:53 am|
|Trevor Perrin||Jul 11, 2003 11:20 am|
|Subject:||Fwd: RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis the OASIS DSS|
|From:||Trevor Perrin (tre...@trevp.net)|
|Date:||Jul 10, 2003 9:49:51 am|
From Ed -
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.
At 09:34 AM 7/10/2003 +0200, Gray Steve wrote:
I apologise for not commenting on the Time-stamping discussion previously, but there are so many emails flying around, I struggle to get to read them all.
No problem, it's getting hectic..
Therefore, I am certainly relying on the requirements document and any changes that are made there. My current interpretation is that Timestamping/Timemarking is a distinct requirement in section 2.12 and 3.7.4
Is my interpretation correct or are you proposing to change this based on your's and Nick's proposal.
There's a bunch of issues swirling around -
My and Nick's proposal, and my last post, were about using the DSS Signing protocol as a timestamp protocol like RFC 3161. If people agree we can use the Signing protocol in this way, we can move to the next issues:
Right now *both* our Signing and Verifying protocols could return a time-stamped signature: 3.7.4 is about using the Verify protocol to get a signature verified and timestamped. The bullet about "signing time" in 3.4.4 is about using the Sign protocol to create signatures that might include a time-stamp.
3.7.5 also covers using the Verify protocol to get "verification info" attached to a signature, perhaps including a timestamp. So we've got timestamps oozing out of everywhere.
A related issue is how to do something like EPM Verify / ApplyPostmark in DSS, where the client uses a single request to both verify a document and get it postmarked, aka time-stamped (or counter-signed, which may be equivalent). For this I suggested letting the client use a single request to send a document and request multiple operations on it, like Verify and Sign (meaning, well, time-stamp).
Ed disagreed with this, but I think his disagreement was more about using the Sign protocol for time-stamping, then about the particular new thing I thought I was proposing (multiple operations per request). However he also made some suggestions I didn't fully grasp: "We simply added options to the primitives that themselves could be primitives... That is why a Verify with a Timestamp option...[is] viable... Again, I recommend you add extensible option directives to every primitive. Options themselves can be primitives". I don't understand this, because the text sounds like he's talking about nesting operations or something, but looking at the wsdl I just see a Verify operation with an ApplyPostmark boolean. Which is simple, and seems about equivalent to what we have with the "Return Verification Info" flag.
Anyways, so the multiple-operations-in-one-request thing might work as the DSS equivalent of Verify / ApplyPostmark. It might also let us eliminate 3.7.4 and 3.7.5. These are bothersome because they use the Verify protocol to produce new signatures, instead of just returning information about old ones. It seems like a number of requirements on the Sign operation would thus apply here: Output Delivery (return the whole thing or just the signature), Intended Audience, Signing Policy, Explicit Signed/Unsigned Attributes..
So if we could send both a Verify and Sign operation in one request, we wouldn't need the "Return Verification Info" flag, because the Sign request would accomplish that function (it would ask the server to produce a signature over the current signature).
Or maybe a better choice is, as Ed says, to define a new operation. VerifyAndSign (or VerifyAndCounterSign) or something, that inherits from both Verify and Sign...
As you can see, your poor editor is quite confused and hopes the TC gives guidance :).....