15 messages in org.oasis-open.lists.dssRE: Fwd: RE: [dss] Fwd: RE: UPU CPC E...| From | Sent On | Attachments |
|---|---|---|
| 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: | RE: Fwd: RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis the OASIS DSS | |
|---|---|---|
| From: | Nick Pope (po...@secstan.com) | |
| Date: | Jul 11, 2003 1:46:47 am | |
| List: | org.oasis-open.lists.dss | |
Ed, Trevor,
I suggest that in the context of DSS we do not confuse a profile for a time-stamp whose semantics is purely this data existed at this time, and a profile for something linked verify which significantly different semantics. Otherwise, as you suggest, there is a threat that a time-stamp against a signature could be misinterpreted as meaning that the signature has been verified.
Nick
-----Original Message----- From: Trevor Perrin [mailto:tre...@trevp.net] Sent: 10 July 2003 23:15 To: ds...@lists.oasis-open.org; Edward Shallow Subject: Re: Fwd: RE: [dss] Fwd: RE: UPU CPC EPM Positioning Proposal vis-a-vis the OASIS DSS
Hi Ed,
So there's 2 issues here: - whether we need a separate Timestamp protocol, or can use the Sign protocol - how to support a Verify / ApplyPostmark operation (i.e. Verify and then Timestamp)
I'll tackle the first, cause I have a definite opinion, and it's a simpler issue. But I'm not ignoring your other points, I'd just like to ponder some more and see what other people say.
At 10:06 AM 7/10/2003 -0700, Trevor Perrin wrote:
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,
The nonce could be added to a "Timestamp profile" (as Nick suggested) of our Signing protocol, as an "Other Signed/Unsigned Attribute" that the client requests to be added into the produced signature or timestamp.
[As a side note, is it really needed? It "allows the client to verify the timeliness of the response when no local clock is available". So it's only useful when: - the client doesn't have a clock - the client isn't using authenticating the server with TLS or similar - an attacker replays a TimeStampResp *that has the same messageImprint* as the requested TimeStampReq from the TSA
All this replay does is give the client an earlier timestamp then he requested. Is this an attack? If so, consider that even with the nonce, the attacker can still *exhibit* an earlier timestamp with the same messageImprint, he just can't replay it within the protocol.
Shouldn't the client just use a binding like TLS, or a clock? And also make sure that it only time-stamps documents that are unique enough that they won't collide with earlier documents, if that's an issue?]
a separate TSA policy,
This is easily handled by our "Signing Policy" requirement.
clock accuracy, the very specific and mandated return of the timestamp token and the timestamp information strucure (i.e. TSTInfo).
This is all stuff that goes into the TST, it doesn't affect the protocol itself, which is already general enough to be used with things as different as XML-DSIG and CMS.
These are all very different from the more conventional Sign request / response structures.
In a previous mail I pointed out all the similarities. In each case, the client sends a hash or a bunch of documents to be hashed as input to creation of a "thingie", and receives back the document with a thingie (signature or timestamp) attached, or just the thingie itself. The client tells the server what the thingie covers, where to place it, whether to return just it or the whole document, what audience it's intended for, under what policy it should be produced, and other things that should be placed inside it. http://lists.oasis-open.org/archives/dss/200307/msg00060.html
I think these commonalities are far greater than the differences you pointed out, and justify making Timestamping just a profile of Signing.
A caller is not even allowed to specify a signing (timestamping) key, that is the TSA's responsibility.
Which key to use we group under "Signing Policy". I don't see why this is any different for Signing or Time-stamping. In either case, the client may choose not to specify such a policy, or implicitly specify one by the server he contacts, or he may go out of his way to request a particular policy.
You will have to create all sorts of pre-conditions on your Sign operation for the TimeStamp requests.
like what?
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
like what?
and you confuse by overloading the Sign with a radically different profile
don't see the differences.
(See Vincent Girier's ISSE XML TimeStamping submission to this group).
On casually skimming it, I don't see anything it does that we would have trouble doing, except we won't define linking schemes in v1. http://lists.oasis-open.org/archives/dss/200212/pdf00000.pdf
It's a good input though, and deserves more study.
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.
We could have Signing and Timestamping protocols inherit from an "abstract base protocol" that contains all the common functionality I pointed out. In that case we'd just have 2 different "verbs" with the same contents. Better not to multiply things unnecessarily, just have 1 protocol and profiles.
Trevor
You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php