RE: [dss] Timestamping

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

Robert,

> -----Original Message-----
> From: Robert Zuccherato [mailto:robert.zuccherato@entrust.com]
> Sent: Thursday, April 03, 2003 2:58 PM
> To: 'Dimitri Andivahis'; dss@lists.oasis-open.org
> Subject: RE: [dss] Timestamping
> 
> 
> Dimitri;
> 
> > Verification of a token issued by a TSA implementing a simple 
> > linking scheme is done by carrying out a verification protocol 
> > with the issuing TSA 
> ...snip...
> >  All communication must be done 
> > over a channel providing data integrity and origin authentication 
> > (for example, by using keys that do not need to last longer 
> > than the transaction lapse).
> ...snip...
> > Any verification protocol with a TSA or other authorized 3rd party 
> > assumes that the verifier has established through out of band 
> > means that the specific TSA or 3rd party may authoritatively speak 
> > for the tokens issued in the name of the TSA named in the "tsa" field 
> > of the timestamp token.
> 
> In other words, in order to verify the token you must still trust the TSA
> (or some other 3rd party) and you must receive the verification message
> protected for integrity and authenticity.  In practical terms, this means
> protected by a signature of some sort, or possibly by a MAC using a
> pre-existing shared key.  Thus, I fail to see the practical advantage this
> scheme has over the traditional RFC 3161-style timestamps.  
> 
> Given that there are also IPR concerns, it is my opinion that the 
> TC should
> not put its effort into supporting these methods at this time.  
> This may be
> something we would want to look at for a 1.1 or 2.0 draft however.
> 
> 	Robert.
> 

The data integrity and origin authentication protection
may be provided at the transport layer, for example, 
through TLS/SSL, SPKM, or any other appropriate protocol.
The parties are assumed to have proper key management 
controls for their SSL keys, shared secrets, or other
appropriate data.  However, the lifecycle of the 
timestamp tokens themselves, once issued, is not dependent 
on the keys/shared secrets and the related key management
controls.

By comparison, traditional RFC 3161-style timestamps
depend totally on the security of the key management 
policies/practices/procedures of the TSA.  
The TSA must implement security precautions similar to 
that of a CA. In the event that the TSA's signing key 
is compromised, the TSA's certificate will be revoked 
and ALL timestamps tokens ever issued by the TSA 
will no longer verify.  Signed tokens depend on 
the key size, and for long-lived timestamping key sizes 
may need to increase.  There are other end-of-lifecycle 
issues, for example, the TSA stopping operations.

The main advantage of the linking methods is that their
security depends only on the security of the hash functions 
used and on the correctness of the computations carried out 
by the TSA (easily auditable). Linked timestamp tokens 
"expire" only when their hash function is broken.
[ISO/IEC 18014-3 recommends that at least
two hash functions be used at every step of the TSA's
computation so that tokens can be renewed securely 
if only one of the hash functions becomes suspect.]
A linked token doesn't depend on the ongoing 
operations of the TSA, as long as a published value 
exists that authenticates the generation of the 
linked token (usually, within days of the generation 
event).  A TSA may go out of business, yet a 3rd party 
with access to the TSA's database of verification data
(what I called A and S values in a previous message)
can provide verification services for all tokens ever
issued by the TSA.

Dimitri