Good questions. I suppose both of these issues could solved using standard x.509 certificates, which may be the next step for TimestampIt. I wanted to avoid using certificates to keep things more simple but it does leave open some issues.

To more directly answer your questions:

> 1. What would happen in the event when the private key was leaked? Is there any scenario for invalidating or rotating keys?

Right now there is no good means of invalidating a key. There is key rotation however, and upon key rotation the private key is completely deleted from all places it is stored. So I am doing everything I can to minimize exposure of the private key, but of course nothing is fool proof.

The verification scripts should be extended to verify that the timestamp occurs between the activation and retirement times for the signing key. You can see these times in the keychain: https://github.com/timestampit/keychain/blob/main/keychain.j... / https://timestampit.com/keychain.

> 2. For verifying the proof file, it seems like the URL for obtaining the signature key[1] is read directly off the proof file[2]. Wouldn’t that allow an attacker to publish proof files that point to their own server, hence allowing the attacker to sign fabricated files and still make them pass the automated validation?

This is a good call out. The verification scripts should check that the key-url has a trusted domain on it. I will make those changes soon.

I appreciate you checking out this project!