|Trevor Perrin||Mar 18, 2003 1:31 pm|
|Dimitri Andivahis||Mar 19, 2003 3:12 pm|
|Trevor Perrin||Mar 19, 2003 8:35 pm|
|Dimitri Andivahis||Mar 20, 2003 4:27 pm|
|jmessing||Mar 20, 2003 4:46 pm|
|Trevor Perrin||Mar 20, 2003 7:41 pm|
|jmessing||Mar 20, 2003 8:42 pm|
|Robert Zuccherato||Mar 21, 2003 7:09 am|
|Robert Zuccherato||Mar 21, 2003 7:36 am|
|Trevor Perrin||Mar 21, 2003 3:10 pm|
|Dimitri Andivahis||Mar 21, 2003 3:35 pm|
|Dimitri Andivahis||Mar 21, 2003 4:07 pm|
|Trevor Perrin||Mar 21, 2003 6:24 pm|
|Nick Pope||Mar 22, 2003 6:58 am|
|Robert Zuccherato||Mar 24, 2003 7:40 am|
|Robert Zuccherato||Mar 24, 2003 7:44 am|
|Robert Zuccherato||Mar 24, 2003 7:51 am|
|Nick Pope||Mar 24, 2003 8:28 am|
|Trevor Perrin||Mar 24, 2003 12:03 pm|
|Gregor Karlinger||Mar 25, 2003 7:39 am||.bin|
|Gregor Karlinger||Mar 25, 2003 8:05 am||.bin|
|kare...@esat.kuleuven.ac.be||Mar 25, 2003 8:38 am|
|Trevor Perrin||Mar 25, 2003 10:48 am|
|Nick Pope||Mar 25, 2003 11:34 am|
|Robert Zuccherato||Mar 27, 2003 11:08 am|
|Gregor Karlinger||Mar 31, 2003 12:07 am||.bin|
|Nick Pope||Mar 31, 2003 4:42 am|
|Dimitri Andivahis||Apr 1, 2003 3:24 pm|
|Karel Wouters||Apr 2, 2003 4:21 am|
|Trevor Perrin||Apr 3, 2003 11:47 am|
|Robert Zuccherato||Apr 3, 2003 11:49 am|
|Robert Zuccherato||Apr 3, 2003 12:29 pm|
|Trevor Perrin||Apr 3, 2003 2:06 pm|
|Dimitri Andivahis||Apr 4, 2003 5:57 am|
|Dimitri Andivahis||Apr 4, 2003 3:00 pm|
|Dimitri Andivahis||Apr 4, 2003 3:24 pm|
|Trevor Perrin||Apr 4, 2003 11:39 pm|
|Trevor Perrin||Apr 7, 2003 11:56 am|
|Subject:||RE: [dss] Timestamping|
|From:||Gregor Karlinger (greg...@cio.gv.at)|
|Date:||Mar 25, 2003 8:05:21 am|
bin00003.bin - 13k
I agree with Nick: If we decide to support only time stamp tokens that can be represented by a signature comprising
* the hash presented the requester together with
* a couple of signed/unsigned attributes
we should conceive a time stamp token as a kind of signature, similar to other use cases we have identified.
* define a syntax for the signature
* define a couple of widely usable attributes
* define a protocol by which the requester can tell the signature service how to combine signature and attributes in order to create a particular kind of signature (in the creation use case), or which combination of signature and attributes is expected by the requester (in the verification use case).
Regards, Gregor Karlinger
I see we have language problem. I see the syntax just a component of the protocol.
I Re-run my argument with syntax instead of protocol.
If we have to define a different syntax for all the different potential semantics of a DSS service then we are going have to define a multitude of syntaxes. Depending on the different inputs and output options being considered the DSS will have different semantics. We have already defined in the use cases which have different semantics: e.g. for individal signatures, corporate seals, delegated signatures, protecting SOAP exchanges, notarisation ..... If we define a separate syntax for each then we will never finish our job. Also, if we do have a separate syntax for time-stamping I am concerned also about the need for a separate syntax for verification of time-stamps.
I also don't want to see a proliferation of protocols in this TC. I think it is entirely reasonable though to have one protocol that returns either a (conventional) signature or a signed time stamp info object, depending upon which is being requested.
I agree with what Trevor has stated in his earlier messages.
If we have to define a different protocol for all the different potential semantics of a DSS service then we are going have to define a multitude of protocols. Depending on the different inputs and output options being considered the DSS will have different semantics. We have already defined in the use cases which have different semantics: e.g. for individal signatures, corporate seals, delegated signatures, protecting SOAP exchanges, notarisation ..... If we define a separate protocol for each then we will never finish our job. Also, if we do have a separate protocol for time-stamping I am concerned also about the need for a separate protocol for verification of time-stamps.
In addition, having taken part in & watched years of discussion on the "non-repudiation bit", the exact semantics, and by implication legal liabilities, associated with signed data is much more than a technical question.
I suggest that a more efficient approach would be as mentioned at the last DSS meeting: that is to define a generic protocol with profiles for specific uses. One of these profiles can be for time-stamping.
My feeling is that the semantics of a TSA's signature is substantially different enough from the semantics of other signatures that it warrants a separate syntax, or <TSTInfo>, for the signed data. Thus, I support option B below.
Let's compare the timestamping scenario with the Corporate Seal use case where only the hash of the data is sent to the server and the server includes a time-mark (as some sort of authenticated attribute). This use case is probably the closest in practice to the timestamping scenario. In both situations the server sees only the hash of the data and in both situations the server is appending the current time in some fashion. The semantics of the two situations are very different though. The TSA is not purporting to have originated the data and is not agreeing to the data in any way. It is simply purporting to have seen the hash at that time. However, in the Corporate Seal use case I argue that even though the server itself has not seen the actual data, the entity that has submitted the data to the server has and thus the server can claim to have originated the data or can agree to the data on behalf of that submitter. This is why authentication to the server in this use case is so important. The server is actually delegating some of it's responsibilities as a signer to the submitter and must authenticate that the submission is from a trusted entity. Thus, the corporate seal provides origin authentication or agrees to the data on an organizational level.
Now, we could still load all of these semantics into some sort of signed attribute and if we could be sure that the attribute would always be honoured, this would likely be fine. However, we don't have any criticality defined for authenticated attributes in most of the signature formats that I can think of. Thus, I believe that it is likely that these TSA signatures will be mis-interpreted. The safe way of doing things, I believe, is to have a separate syntax for timestamped data.
The requirements subcommittee is considering what the requirements should be for a timestamp format and protocol. We'd like some input from the group, since this hasn't had much discussion yet.
Currently, the notions of time-marked signatures and time-stamped signatures have been defined:
A time-marked signature is just a signature on some content with a signed attribute (created by the signer) containing the signing time.
A time-stamped signature contains, as an unsigned attribute, a timestamp "token", which somehow binds the time and a hash of the time-stamped signature's signatureValue, and is created and signed by a 3rd party TSA (Time Stamp Authority).
More generally, a timestamp token may be used to timestamp other things than a signatureValue.
Now, whatever format the timestamp token takes, a timestamp protocol just requires the client send a hash and receive back a token. This shouldn't be any different from the DSS protocol used in the "client-side hashing" and "receiving a detached signature" case. Thus, time-stamping should just be a use-case of the DSS protocol, not a separate protocol.
As for an XML timestamp token format, there's two approaches: A) Define a time-stamp token as just a time-marked signature produced by a 3rd-party that's trusted as a TSA. B) Define a time-stamp token as a signature on some new <TSTInfo> structure containing a hash of the to-be-timestamped data and the time.
In (A), the TSA produces a normal signature using the hash of the to-be-timestamped data, with time as a signed attribute. In (B), the TSA combines the hash of the to-be-timestamped data with the time into a new structure, and produces a normal signature on that. (B) is the approach used in RFC 3161, which is PKIX's timestamping protocol, and is used to timestamp CMS signatures.
The benefit of (A) is that timestamps aren't handled differently from any other signature type, they're just a particular "semantics" instead of "syntax". The argument against this, is that timestamps *are* different from other signatures: Normally signatures testify that the contents are associated with the signer as an originating entity, not that the contents are associated with a time. So timestamps should have a different syntax to ensure that they're processed correctly, and that a Relying Party understands that the time is the important thing, and doesn't mistakenly ignore a signing-time signed attribute and think the TSA originated the to-be-signed data.
One way of framing the question: what are the semantics of a raw, DSIG signature? If a DSIG signature is just a statement of the form "someone says something about some data", where - the speaker ("someone") is identified with a <KeyInfo> - the object ("some data") is identified with a <SignedInfo> - the predicate (what is being said about the object) is identified by the <KeyInfo>'s properties/policy identifiers and signed attributes
Then asserting that the data existed at a certain time is just another predicate that can be asserted about <SignedInfo>, along with asserting that you originated it, or asserting that you agree to its contents, or asserting that it really came from some Identified Requestor.
But if a DSIG signature also carries the semantics that the signer originated the data, then it would be misleading for a TSA to produce a signature on the to-be-timestamped hash while relegating the signing time to a signed attribute (but then wouldn't any use case where the server didn't originate the data, but just signed a hash, be misleading?).
But that may be unfair (I'm biased towards A). What do other people prefer?