The accepted answer here is absolutely wrong!
The timestamp is signed with a certificate issued for the specific purpose of signing timestamps. This certificate has its own expiration time and validity period, which is usually longer (much longer for sha256) than the validity period of a certificate issued for SSL/TLS/code signing, however, not infinite (answer to your 3rd part). Also, it is not your cert, it is on secure server. As soon as the certificate used to sign a timestamp expires, the timestamp expires as well. As per section 4.3 of RFC 3161, such a timestamp should be redone or notarized to renew the existing trust in the timestamp.
If the timestamping certificate is revoked (claimed as invalid by the CA that has issued it), there are two cases possible, as per sections 4.1 and 4.2 of RFC 3161:
If the revocation reason code indicates that the key has not been compromised but the TSA itself will not be operating in the future, then the timestamping certificate should not be used for timestamping in the future (after revocation). Previously made timestamps, however, don't become invalid.
If the revocation reason code indicates code compromise, then all timestamps signed with the compromised certificate become invalid.
Moreover in one system there even existed OID 1.3.6.1.4.1.311.10.3.13 that forced any timestamp cert to be not used after expiration of signing cert. http://web.archive.org/web/20160405182742/https://forum.startcom.org/viewtopic.php?f=15&hilit=lifetime+signing&p=6827&t=2215