[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notary systems requirements


At 14:32 13/09/01 +0200, Alfonso De Gregorio wrote:

what about to start to working on a document that collects requirements
for notary systems based also on TSAs?

In my opinion, the current TSP don't allows always the use of a
time-stamp token as a proof-of-authorship, because the security
analysis of the protocol don't address the possibility of a
deliberate replay attack by a middleman replaying legitimate TS
_requests_;...

<snip>

To avoid this attack, Alice must be required to hash the sign the 
document she wants to  time-stamp; compute the hash over the signature
of the signed data and set the messageImprint field of time-stamp
request to the computed value (similarly to what is required in
Appendix A, for the proof sign creation before corresponding certificate
revocation).

Correct. This would be wise anyway if you want to counter Rabin's attack i.e. make your own peculiar alteration to the base data - what you suggest is just that. If the TSA chooses to work by 'open declaration' of its timestamping records then this also can help check what is claimed to be happening. The courts will examine the evidence available and make their own judgement.

TSAs may well not want to respond to unsolicited requests (a) to avoid DoS attacks and (b) to ensure only paid-up subscribers get the service. Therefore, there must be some identity/source checking going on and the courts may take some notice of this. However, this is outside the scope of TSP.

As someone who is interested in wider uses of TSP I would support looking at these. However, I do not think this forum is the right place? PKIX thrust is enabling and, in TSP, it has enabled. Yes?

Adrian Pickering/
Electronics and Computer Science
University of Southampton, UK