RE: [dss] Timestamping

[Trevor Perrin <trevp@trevp.net>]

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.

Trevor


At 10:17 AM 3/21/2003 -0500, you wrote:

>Trevor;
>
>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.
>
>         Robert.
>
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
> > Sent: Tuesday, March 18, 2003 4:38 PM
> > To: dss@lists.oasis-open.org
> > Subject: [dss] Timestamping
> >
> >
> >
> > 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?
> >
> > Trevor
> >