RE: [dss] Timestamping

["Dimitri Andivahis" <dimitri@surety.com>]

Trevor,

> -----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).
> 

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.

> 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.

> 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  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
> 

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).

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?

Take care.

Dimitri