[forgotpwd16]

>so that we can be sure we are verifying the correct PDF

Umm, what? Someone cannot create a PDF and sign with someone else's key. This would've defeat the purpose of public-key cryptography.

>it's not a great storage mechanism for this system to scale to thousands or millions of signatures

Not sure how recommending a system that scales not on signatures but on messages shared is better.

>Another alternative is these messages are broadcast through a public and decentralized ledger.

Okay. So suppose a message was distributed from an address. How you know to whom this address belongs? How will be different that you being shared their public key?

[web3isgoing]

Vitalik, or maybe a charitable non profit organization, signs two PDFs: one says "our new public key is X" and the other says "our new public key is Y." Both of these documents verify correctly, but how do you know which is the latest? One approach is to use Twitter as your append-only timestamped ledger, and broadcast a link to the latest file on IPFS. Another is to build a new centralized service and promise it is secure and will not get hacked or mutated. Another is to rely on a public distributed ledger that is verifiably secure and strongly resistant to modification.

[pclmulqdq]

How about he doesn't sign the PDF that is wrong?

If you're imagining that this is part of some key rotation procedure, what about signing a document that says "until April 20th, 2022, 0:00 UTC our public key is X"?

And then if the central source gets hacked, people will be suspicious of the PDF for a few hours, but nobody will do anything disastrous.

Edit: you can also add chaining to the documents themselves: "until... the private key is X. This document supercedes the doument with hash Y."

[web3isgoing]

In this example it is key rotation, but you do not know when your key will expire, so you cannot put that in the message. Imagine you have a key, and later realize it may or may not be compromised, so you decide to rotate.

You can be in the habit of writing "I signed this message at date K" but if any of your old keys are compromised, the hacker can sign a new message with today's date to spoof a new rotation event. Without ordering these events by time, you cannot know which is the newest.

One solution is to have a log showing the timestamped key rotations. A company can store everybody's timestamped key rotations on a sqlite database and promise it won't ever be modified, or you can put these state changes in a distributed ledger. If the value of the key rotation events outweighs the cost of submitting transactions to the ledger, it may be worth it. This is unrealistic with Eth L1 but more realistic in something like a recursive zk rollup on L2.

[pclmulqdq]

The documents themselves are the log. You don't need "zk rollup on L2" to make a verified chain of documents. All that's left is the distribution method.

For that, you put them on your website, using proper security. You put them somewhere where you (and your users) have legal recourse if something goes wrong. That is the safest place to put your public keys.

Also, if your keys are compromised, a blockchain solution is completely and forever corrupted. A website is only corrupted for a few hours until you regain control.

[web3isgoing]

A document is not a ledger. The blockchain is the distribution mechanism.

[propogandist]

> rely on a public distributed ledger

which brings us back to the point that the ETH foundation is trying to link LibreOffice to ETH cryptocurrency