|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 20, 2003 7:41:26 pm|
Are there public docs for the ISO standards? They'd be interesting to look at,
ISO makes money by selling standards documents, so their docs are usually NOT available to the general public for free. There are a few people on this TC who have access to the ISO time-stamping documents. I will check with the ISO admin folks, see if they would allow us to share.
It would be great if they were willing to make this a submission.
But are these methods practical, and worth the effort? If so, what requirements should be added for them?
I believe they are practical. A commercial implementation of a digital timestamping service using linking methods has been available on the Internet since 1995. A TSA practicing linking methods is not required to sign the submitted hash, time value and other info within the timestamp token, and this may be an advantage in various situations (key management issues, long-lived timestamping).
Gregor's submission goes a long way towards providing support for it. We would need to define a protocol for timestamp-token verification, similar to what's done in ISO 18014-1. I am offering to contribute to any additional work this may require.
It defines an XML format for linked timestamps. But what are the protocol requirements for a linked timestamp service, above and beyond those required for a "simple" timestamp service (i.e. one that just signs the hash and time)?
For example, suppose the aggregation round lasts longer than the client is willing to wait to get his timestamp. Does the client get a ticket or something, and come back later to retrieve the finished product? Doesn't the service need to broadcast the aggregation round values, in such a way that 3rd parties will archive them and they won't be tampered with? Does that require another data format and protocol? And won't a verifying party need a protocol to retrieve these round values from the 3rd parties?
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..).
Not exactly. A TSA using a linking method doesn't have to sign anything that goes in the timestamp token.
Agreed, linking is more complicated. But a "simple" timestamp, which is just a ds:Signature over the time and hash, could be easily accomodated in a DSS protocol, I think.
In the binary protocols world of ISO 18014-3, the returned timestamp token may be a value of type SignedData (for TSAs who link and sign) or DigestedData (for those who link only). In XML, there are minOccurs="0" attributes for the various alternatives, as shown on page 18 of Gregor's submission.
Requests for timestamp tokens produced using MACs, as defined in ISO 18014-2, could be made to fit in your XML DigSig DSS protocol. However, verification of timestamp tokens produced using MACs requires that a verification protocol with the issuing TSA be conducted, since the TSA is the only entity in possession of the secret key(s).
There will be a DSS verification protocol as well as signing, which should take care of that.
The more general issue is, I don't think you can use the same protocol (i.e., the same request and response objects) for disparate services, such as requesting a generic digital signature and a timestamp token issued by a TSA. There are many requirements placed on the TSA generating a timestamp token that have nothing to do with the fact that it may be generating them as XML signatures over some data. These requirements are reflected in the contents of the timestamp token returned,
Requirements placed on the type or contents of the token produced (public-key signature, MAC, simple or linked timestamp), might only affect the payload of the response message, but not the request message.
For example, there's a lot of complexities around how the client submits the data he wants signed or timestamped. In XML, the client could transform these data himself or not, hash them himself or not, send a whole document even when he only wants parts of it signed, or only send those parts, etc..
This part of the protocol might be exactly the same for a digital signature service, a "simple" timestamping service, or a "linked" timestamping service. So maybe this indicates that the core DSS protocol should be a generic "submit document, receive cryptographic token based on document" protocol, instead of just a "digital signatures" protocol, since much of the protocol details will be about document submission, but be indifferent to what type of token is actually produced.
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).
OK, that clears up the definition of time-marking. However, see top of page 7 for their argument over "timed signature" and TST.
I don't think those differences are major, as they claim. The TSA may only have access to the hash, but it can still produce a DSIG, that's just a protocol detail. The example is simplistic, but it didn't have to be, you can put the same contents from an RFC 3161 TSTInfo into the signed timestamp attribute (though you would omit the messageImprint).
This makes time-stamping more consistent with other function a DSS service
I would substitute "time-stamping" to "time-marking" in the sentence above.
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.
Again, I would substitute "time-mark the document" above.
That's my point though: a time-mark can serve just fine as a simple timestamp, if it's produced by a party trusted as a TSA.
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.
Agreed, the notary is a TTP that checks the digital signatures, and signs over the data submitted and a time attribute that may be trusted. The notary would have to follow the same requirements for trusted time as a TSA, even though technically it's not a TSA. Will the same requirements apply to all time-mark providers?
I know what you describe is a common crypto definition of a notary service. I was thinking more like John Messing's eNotarization use case though, where the document is not signed by the end-user, but rather the end-user submits the document to the notary service and authenticates himself to it somehow, and the notary service then signs the document with its private key, while attaching the name of the end-user and the time as signed attributes.
If the relying party trusts the notary to be authoritative for time, and the notary service adds some policy identifer to indicate that he means for this to be a time-stamp, then I'd call it one. And this way of timestamping is convenient, cause the notary can both assert the requestor's identity and assert the timestamp within a single ds:Signature.
But I don't think every time-mark would have to be a time-stamp, if you just want to toss in <SigningTime> for informative purposes, but don't expect anyone to take it seriously, then it wouldn't be a timestamp..