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: | Robert Zuccherato (robe...@entrust.com) | |
| Date: | Mar 24, 2003 7:40:49 am | |
| List: | org.oasis-open.lists.dss | |
Trevor;
I also agree. I think that in the end we can go with either approach and come up with a token format that is acceptable. However, I believe that the semantics of the timestamping case are different enough to warrant a different syntax. Certainly this is how PKIX felt and that is why they developed the syntax they did. Now ISO/IEC and ANSI are adopting this model. I don't think that we should simply adopt a certain model in this TC just because others are doing so, but I think it is worthwhile to ask ourselves why they are all adopting this model and see if the same reasons are appropriate here.
Regarding you point of the "Identified Requester" use case, I think that even in this case the server is signing the document, with the intent of proving origin or expressing agreement (at some level). However, they are performing this signature on behalf of someone else. That information (who the "someone else" is) should be available if it matters to the relying party, but isn't always important.
If a Review Authority is signing documents to signify approval, then I would argue that this is a form of agreeing with the content of the document.
Robert.
-----Original Message----- From: Trevor Perrin [mailto:tre...@trevp.net] Sent: Friday, March 21, 2003 6:19 PM To: ds...@lists.oasis-open.org Subject: RE: [dss] Timestamping
Hi Robert,
I see your point - a signature implies that the signer agrees with or originated the signed data, so a timestamp shouldn't be a signature.
My feeling is that the above may be the legal or semantic meaning of an "electronic signature", but a cryptographic signature shouldn't be assumed to have any semantics beyond "the signer is trying to say *something* about the signed data". The relying party shouldn't make any assumptions about the intended semantics unless he knows the policies/keyUsage bits etc. associated with the key, or placed in the signature itself.
This is an interesting issue cause it has ramifications for things besides timestamps. For example, the "Identified Requestor" scenario. If your point is true, and a signature implies the signer originated/agreed with the signed data, then the Requestor Identity shouldn't be added as a signed attribute either, for the same reasons - we can't be sure the attribute would always be honored, and the signature might be misinterpreted as saying the signer agrees with the data, when really only one of the requestors does. So there should be a <RequestorInfo> much like <TSTInfo>.
Or consider a Review Authority that looks over documents and stamps them "Approved" or "Denied". If such an Authority stamps a document denied, than he is neither originating it nor agreeing with it. I'd prefer for him to attach a <ReviewDecision> as an attribute, rather than signing a <ReviewInfo> structure. If he was attaching semantics as signed attributes, then he could timestamp a document, identify the requestor, and approve or deny it by attaching the appropriate signed attributes within a single ds:Signature. Otherwise he would need to generate 3 separate signatures and link them together somehow.
So I don't think the timestamp case itself is that important - doing A or B would work fine. I'm just wondering what sort of precedent this sets for asserting semantics about documents.