Feedback on TimestampIt! carried over from RFC3161.txt

gistfile1.txt

This gist is carrying over a discussion from a different gist: https://gist.github.com/Manouchehri/fd754e402d98430243455713efada710?permalink_comment_id=5147220#gistcomment-5147220

This gist was started so as not to disrupt the original purpose of that gist which is compiling a list of working RFC3161 TSA servers (with thanks to @Manouchehri for compiling and maintaining that gist).

@JohnPlanetary gave some nice feedback in this comment: https://gist.github.com/Manouchehri/fd754e402d98430243455713efada710?permalink_comment_id=5151554#gistcomment-5151554

I am replicating the comment here:

> timestampit without RFC 3161 and RFC 5816 support doesn't make a lot of sense here in these topic. In fact I would argue that since RFC 3161 and RFC 5816 are the standards and are supported by so many programs that is still relevant, the magic part should be the part to be able to verify in the future that the file was really timestamped 23 years ago... I've been testing TSA's for a long time and basically is almost impossible once the TSA expires to proof anything since it will start to give errors... since CRL and or OCSP usually stop working and stops being possible to verify anything.
> 
> timestampit could have say a different key for every year using RSA 8192 bit SHA512 key to timestamp using RFC 3161 and RFC 5816, and say 150 years of year key lifetime, the main Root with say 500 years lifetime, RSA 16384 bit SHA512. and every year a new key with 150 years of key lifetime.
> 
> > TimeStampit Root Key (RSA 16384 bit SHA512) [From: 2024-08-12 - Until: 2524-08-12]
> > > TimeStampit 2024 Key (RSA 8192 bit SHA512) [From: 2024-08-13 -> Until: 2174-12-31] [signs between 2024-08-13 00:00:00 until 2024-12-31 23:59:59]
> > > TimeStampit 2025 Key (RSA 8192 bit SHA512) [From: 2025-01-01 -> Until: 2175-12-31] [signs between 2025-01-01 00:00:00 until 2025-12-31 23:59:59]
> > > TimeStampit 2026 Key (RSA 8192 bit SHA512) [From: 2026-01-01 -> Until: 2176-12-31] [signs between 2026-01-01 00:00:00 until 2026-12-31 23:59:59]
> > > TimeStampit 2026 Key (RSA 8192 bit SHA512) [From: 2026-01-01 -> Until: 2176-12-31] [signs between 2026-01-01 00:00:00 until 2026-12-31 23:59:59]
> 
> If the CRL('s) can be included within the signature (still doesn't happen in most programs) then theoretically the timestamp could be believed until its expiration date... as long the company itself doesn't have any troubles coming up like the private key being stolen or cracked.
> 
> RSA 16834 bit key with SHA512 should be fine for the Root, but usually can't be used for the final signing key because it will give too many errors at least in my tests it would fail on most signing programs because would take too many memory/ space reserved for the signature.
> 
> NIST P-521 could theoretically be used but the problem is that in reality the security level of it should be lower than even RSA 3072 bit key at least if quantum computing is used to try to find the private key.
> 
> Ok... but what if TimeStampit doesn't want to support RFC 3161 and RFC 5816? In what it would be different from other services online like: https://truetimestamp.org , https://opentimestamps.org , https://tzstamp.io , https://timestamp.decred.org and https://notbot.me ? What happens if TimeStampit closes in 6 years time, how would people be able to prove to others that timestamp is real? Some of the services above include some sort of bitcoin or other coin integration to make it more easy to proof in the future (as long those continue to exist)... in some cases judges may not accept them since it wouldn't be easy to verify by themselves and they may or may not believe experts, if it seems magic mumbojumbo... and to my knowledge there is no standard log database for timestamp similar to Certificate Transparency (where people can search for the certificate from multiple sources using for example: https://crt.sh ) where I think the certificate companies need to publish to more than one log database (at least one being from others not related to that company) in order for others to trust it and be able to verify things after the fact.

Using social media for hash deposit has already been done, for example by originstamp, and if I record it correctly their account had troubles because Twitter identify the use of the account as abusive since they were probably using some bot to publish the information. I think they had to stop use Twitter for that (hash publishment), and any other social media will be subject to the same problem since any of them can decide at anytime they don't like that use and ban the person... of course one can have its own server with some social media application running but that would just be resource intensive, it would open a world of security troubles to take care... it would make more sense to just publish some log file of everything that could be searched on a webpage interface, and maybe even have for example some year/ month/ day folder structure where the main log would be cut to that specific day to make public indexing by third parties (like: https://archive.org/web/ and for example: https://archive.ph and common search engines) easier. And so html pages could be both PGP signed and the html file itself could be signed with for example some PKI digital certificate (.p7b format for example) using for example RSA 16384 bit SHA512 certificate for the owner and some timestamp. And include in the html file itself the OpenPGP key used and the PKI certificates used and the URL to find them on the web site (also available in html to allow easily index of it by third parties archievement web sites, to allow users and expert easier verification even if the service vanishes in the future).

"Having some kind of token based market where users making timestamps pay a token to node operators who maintain the distributed hash table (or blockchain) could incentivize keeping the network operational."

Yes, these is being done by some timestamp operations using bitcoin and other coin based systems, so it shouldn't be impossible. But if it is some distributed hash table or blockchain for just timestamp purpose (to make it faster) it will probably be harder to have a lot of people supporting the network, unless it becomes a standard in the industry and people can make real money with it. Specially the "distributed hash table" would be harder because with more and more people on the network the payment would go down and down to possibly near absolute nothing... at least I'm not seeing the possibility of charging even one cent of dollar to pay 10 000 database holders... each timestamp would cost 100 dollars, eh eh, not very realistic... I know no one that would accept such high prices. Lets not forget that not enough people will maintain a database network if they can't make money out of it somehow... of course those providing the services would be incentivise to do it, and maybe also some courts and similar, but not everyone so the success would be difficult (success in the sense of having a lot of databases around from multiple sources).