Alright I'll bite - why do all this blockchain hoopla instead of just using SMIME/CMS's trusted timestamp feature? That already works fine with git signatures.
Personally I'm pretty against bitcoin et all for their wastefulness (PoW) or lack of improvement on existing systems (PoS), but I can definitely see trusted timestamps as a valid use of a public ledger. Ironically, since git is implemented as a merkle tree, you could do this quite easily in git as a "blockchain" minus the Proof of *. So, no distributed trust, but I'm personally usually glad to trade a little bit of centralization for a whole lot of performance/efficiency.
We are on the same page. I do think there are some gains, although I question the use of "permissionless" blockchains (we have to remember to add this caveat now since we decided 90s tech should now be called "permissioned blockchains"). A simple published ledger ("immutable append-only", like CT logs) seems like a much easier route. If nodes care enough, they can poll it and alert when the tip changes in a way that should not be allowed.
"trustless" is not the word here... you are trusting the economic incentives of the blockchain system to remain in-tact. But I do agree with you that one could feasibly trust it "more" than a single entity protecting a key and acting correctly. However in practice "more" comes with a very very hefty price tag, in my experience one that makes it completely impractical in the real world. Look at the verification requirements:
- run a full bitcoin node, download the full blockchain
- wait several hours after the timestamp is produced for the system to publish to blockchain (which also reduces the granularity of the timestamp, within this window the system is only "as secure" as a solution trusting a single entity)
- download all the commits in the Merkle tree that was signed and published, and search for the commit you are verifying within the tree
Security in practice is about tradeoffs, and I can't imagine a scenario wherein these tradeoffs would work for me without ultimately having a centralized provider verify them for me, at which point I just have complexity with no gain over the traditional trusted timestamps.
Yes, because it's very small list of companies that have trusted timestamp servers and follow a strict set of rules re: key storage, rotation, issuance, etc.
TBH this is a good argument not to trust timestamp servers. AFAIK usually you just want to stick to one, and not treat a group of them interchangeably (ala the Internet Root Bundle). In any case, the owners of the repo (or email message) would decide for themselves which one(s) they want to trust.
We do use just a specific one at work. My point was that it's a highly secured process limited to just a few companies, and becoming one is a lot of effort, if at all possible. There are even some RFC3161 servers just not trusted by Windows, ergo: useless for most timestamping uses.
