38 messages in org.oasis-open.lists.dssRE: [dss] Timestamping| From | Sent On | Attachments |
|---|---|---|
| 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: | Trevor Perrin (tre...@trevp.net) | |
| Date: | Mar 19, 2003 8:35:38 pm | |
| List: | org.oasis-open.lists.dss | |
At 06:21 PM 3/19/2003 -0500, Dimitri Andivahis wrote:
Trevor,
-----Original Message----- From: Trevor Perrin [mailto:tre...@trevp.net] [...] 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).
One comment on the last sentence above: 3rd party TSAs may be using techniques other than digital signatures to bind the time and the hash and generate the timestamp token.
For example, the TSAs defined for the binary protocols universe in the ISO 18014-1,2,3 timestamping standards use digital signatures, MACs or linking methods. If you are not familiar with them, the ISO standards extend the protocols and data types defined in RFC 3161 and are fully compatible with RFC 3161 when the digital signatures method is used.
In the XML world now, there were timestamping input documents submitted to this TC that contain XML Schemas covering all methods of timestamping, not just the one using digital signatures.
Are there public docs for the ISO standards? They'd be interesting to look at, since most of the timestamping submissions to the TC seem inspired by RFC 3161 (these are the ones I remember): http://lists.oasis-open.org/archives/dss/200211/msg00003.html - Entrust http://lists.oasis-open.org/archives/dss/200212/msg00004.html - Juan Carlos Cruellas http://lists.oasis-open.org/archives/dss/200212/msg00012.html - EML http://lists.oasis-open.org/archives/dss/200301/msg00001.html - Gregor Karlinger
As for linking methods, only Gregor's submission discusses supporting them in detail (though it does a good job). But are these methods practical, and worth the effort? If so, what requirements should be added for them?
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.
I don't think the timestamping protocol should be confused with the DSS protocol. The semantics of the two processes, requesting a digital signature from a server vs. requesting a timestamp token from a TSA, are totally different. Let alone, this is a non-starter if the TSA generates timestamp tokens using a linking method or a MAC. I think almost all XML Schemas for timestamping that were submitted to this TC capture the complexity of the timestamp request/response process and account for the need for a separate timestamping protocol.
Could you elaborate? Aside from linking, the above protocols all just send a hash, and receive back a signature on the hash and time. This doesn't seem any different than sending a hash and receiving back a signature on the hash and any other signed attribute (such as requestor identity, signature policy, etc..).
[...]
My opinion is that we should have a separate timestamping protocol for communicating with TSAs, for the reasons I described earlier. In the interest of avoiding confusion with other timestamping standards in the non-XML universe, I would also propose keeping timestamp tokens separate from time-marks, if they are indeed different objects. I'm a bit unclear on the issue of time-marking in general. I've seen a short definition in ETSI 102023, but there was little detail.
Could any cryptographic binding between a submitted hash and a time value qualify as a "time-mark", as long as the time-mark server archives "something" for each request and maintains a secure audit trail, against which each "time-mark" issued may be validated? If so, any of the TSAs defined in other timestamping standards could be extended to do a bit of archiving and offer time-marking services (time mark == timestamp token).
I was hoping a time mark was just when a signer adds a signed attribute containing the time.
Maybe better terms come from Juan Carlos' submission, which says (in 3.2) that adding such an attribute creates a "timed signature", but not a "signed timestamp". I was thinking maybe a "timed signature" is a better way of doing a timestamp, because it keeps separate the data the signer is referring to (the <SignedInfo>) and what the signer is asserting about it (the signed attributes).
This makes time-stamping more consistent with other function a DSS service might provide (like signing contracts, or identifying requestors), and this consistency would let a DSS service make multiple assertions about a document in a single signature. For example, a notary might want to both - attest to the identify of the requestor - attest to the time of the request (i.e. timestamp the document)
If both <RequestTime> and <RequestorIdentity> could be attached as signed attributes, then the notary could both timestamp the document and identify the requestor within a single ds:Signature.
Are there interesting cases of non-TSAs that offer some type of time-marking service? If so, what precludes them from being full-blown TSAs?
Maybe the notary service above? I'd say such a service is a "TSA" if TSA just means someone trusted to be authoritative for time by some relying party. Or maybe you wouldn't consider it a TSA, since it doesn't provide timestamping as an individual service, only in conjunction with authentication and requestor identification. I dunno.
Trevor