[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Timestamping
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]