RE: [dss] Timestamping

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

Dimitri;

It is true that both ISO/IEC 18014 and ANSI X9.95 include the linking
methods of timestamping.  However, the scope of these efforts is broader
than ours, which is to "support the processing of digital signatures" and to
prove "that a signature was created within its key validity period".

The linking methods, by themselves will only tell a relying party that a
timestamp was issued in the time between the issuance of two other
timestamps.  By linking all timestamps together like this, confidence can be
obtained in the authenticity of the timestamps.  This is a useful service in
some environments.  However, when a relying party needs to know the absolute
time that a signature was applied it doesn't directly help.  In order to
obtain that additional information a signature a time value must usually be
included in the token.  Thus, the linking protocols provide, to my
knowledge, little additional value to the hash and sign methods.

I believe that there are also IPR issues associated with the linking methods
of timestamping.  I would encourage all TC members to familiarize themselves
with the OASIS IPR policy
(http://www.oasis-open.org/who/intellectualproperty.shtml) and make sure
that they are in compliance.

	Robert.

> -----Original Message-----
> From: Dimitri Andivahis [mailto:dimitri@surety.com]
> Sent: Wednesday, March 19, 2003 6:21 PM
> To: dss@lists.oasis-open.org
> Subject: RE: [dss] Timestamping
> 
> 
> 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
>