RE: [dss] Timestamping

[Robert Zuccherato <robert.zuccherato@entrust.com>]

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:trevp@trevp.net]
> Sent: Friday, March 21, 2003 6:19 PM
> To: dss@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.